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SUMMARY 


This  paper  describes  the  relationship  between  the  Air  Force's  Systems  Engineering  (SE) 
approach  to  weapon  system  design  and  acquisition  management,  and  manpower,  personnel,  and 
training  (MPT)  estimation.  A  practical  interface  between  SE  and  MPT  is  proposed  to  serve  as  a 
basis  for  MPT  resource  allocation  and  trade-off  technology  for  use  in  design  engineering.  This 
interface  relies  on  Measures  of  Merit  (MOMs)  for  human  resources  variables  and  integration  with 
established  processes,  particularly  Logistics  Support  Analysis  (LSA).  MPT  Process  and  Data 
Models  are  also  proposed  as  an  analytic  framework  for  development  of  useful  new  analysis  tools 
for  human  resource  reckoning. 

Candidate  MOMs  identified  for  further  study  are: 

1 .  Maintenance  Tasks  by  Subsystem 

2.  Reliability  by  Subsystem 

3 .  Maintenance  Task  Times 

4 .  Maintenance  Crew  Size  by  Task 

5 .  Manpower  by  Air  Force  Specialty  (AFS) 

6 .  Manpower  Slots  per  Primary  Assigned  Aircraft  (PAA) 

7.  AFS  Structure 

8 .  System  Training  Requirements 

9 .  Required  Accessions  by  AFS  per  year 

Future  development  of  TDSTL  depends  on  credible  ways  of  measuring  these  MOMs  and 
on  better  ways  of  estimating  the  critical  manpower  variable.  These  issues  are  discussed  in 
connection  with  SUMMA  (Small  Unit  Maintenance  Manpower  Analyses)  and  Hardman  III,  two 
new  human  resources  technologies  that  seem  especially  relevant  to  TDSTL  development. 
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PREFACE 


The  research  was  performed  for  the  Air  For;e  Human  Resources  Laboratory  by  Systems 
Exploration,  Inc.  under  Task  Order  23  of  Contract  F33615-88-C-0004.  The  AFHRL  Work  Unit 
is  2940-00-01.  The  research  was  undertaken  in  support  of  MPT  Research  Need  A89I030  entitled 
"Optimizing  Trades  Between  Weapon  System  Design  Parameters  and  Manpower,  Personnel,  and 
Training  Factors  Using  Engineering  Top  Down  Design  Allocation  Methods." 
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I.  INTRODUCTION 


Purpose 

The  purpose  of  the  Top  Down  System  Tool  for  Logistics  (TDSTL)1  research  is  to  develop  a 
useful  framework  for  implementing  Manpower,  Personnel,  and  Training  (MPT)  analysis  in  the  Air 
Force.  MPT  technology  development  efforts  here  and  elsewhere  stand  to  oenefit  from  a  more 
rigorous,  pragmatic,  and  specific  statement  of  MPT  requirements  and  goals  as  they  apply  to  the 
existing  acquisition  process.  Hence,  in  this  phase  of  TDSTL  research  our  strategy  has  been  to 
identify  as  exactly  as  we  can  what  the  MPT  data  and  analysis  requirements  really  are,  and  how  they 
can  be  assembled  into  an  analysis  framework.  To  do  this  we  have  adopted  the  Systems  Engineering 
(SE)  model  of  system  design  as  the  preferred  framework.2 

The  SE  management  and  logistics  analysis  activities  applicable  to  MPT  are  here  named  the 
MPT/SE  Process  Model.  This  definition  forms  the  basis  for  a  description  of  data  and  algorithms 
used  within  the  MPT/SE  arena,  which  is  called  the  MPTISE  Data  Model.  The  MPT/SE  Data  Model 
then  becomes  the  primary  basis  of  proposed  measures  of  merit  (MOMs)  for  MPT  analysis.  These 
MOMs  become,  in  turn,  the  basis  for  new  research  that  will  develop  a  more  complete  model  for 
MPT  analysis  within  the  SE  process. 

The  class  of  models  broadly  classed  as  MPT  is  already  quite  large,  and  some  are  known  to 
be  useful  and  useable.  The  major  problems  with  most  of  these  MPT  tools  are  that  they  are  more  or 
less  detached  from  the  design  engineering  ethos,  and  segregated  within  remote,  irrelevant  islands. 
In  contrast,  the  TDSTL  has  a  frankly  pragmatic  outlook,  attaching  MPT  to  the  real  world  as  we  find 
it,  and  seeking  relevance  as  much  as  perfection  for  MPT  applications. 

The  TDSTL  research  described  here  is  linked  to  a  companion  effort  called  Integrating 
Manpower  Analysis  with  Computer-Aided  Design,  or  IMACAD.  The  IMACAD  research  will 
prototype  and  evaluate  an  automated  design  manpower  interface  with  SE  using  computer  graphics 
workstation  technology.  The  basis  for  this  linkage  will  be  the  MPT/SE  Process  and  Data  models 
developed  in  the  TDSTL  research. 


1  The  TDSTL  abbreviation  is  pronounced  "Toadstool." 

2  Sec  MIL-STD  499A  "Engineering  Management"  for  a  detailed  description  of  Systems  Engineering  ideas.  Other 
useful  information,  though  unpublished,  is  found  in  the  "ASD  Systems  Engineering  MPT  Notebook"  (ASD/ENET) 
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Background 


The  technical  management  model  underlying  all  large  Air  Force  systems  is  the  SE  process, 
which  consists  cf  five  steps.  Figure  1  relates  the  SE  process  to  the  WSAP,  or  Weapon  System 
Acquisition  Process. 


WSAP 


SE 


Q  Pre-Concept  J 


^Concept  Exploration  J 


1.  Develop  Functional 
Description 


^Demonstration  and  Validation  ^  ^ 


(  2.  Assign  Functional  Allocation  ^ 
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Full  Scale  Development/ Low-Rate 
Initial  Production 


Production/Deployment  ^ 
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r  n 
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System 
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Performance 

■ 

Specification 

i  J 

■ 

Figure  1.  WSAP  and  SE  Process. 


The  Five  Steps  of  the  System  Engineering  Process 

1.  Develop  Functional  Description.  The  system  functionality  is  determined  by  developing 
candidate  strategies  that  might  fulfill  some  set  of  mission  requirements.  For  example,  an  Air  Force 
requirement  may  be  to  attack  an  air  base  100  km  behind  the  enemy’s  forward  position.  Two 
candidate  functional  descriptions  may  be  proposed:  (a)  an  aircraft  capable  of  carrying  a  sufficient 
payload  at  high  speed  without  being  detected  by  radar,  or  (b)  an  unmanned  cmise  missile. 
Competing  candidate  functional  descriptions  are  evaluated.  A  final  functional  concept  for  a  weapon 
system  is  selected  and  fully  developed.  The  functional  description  contains  system  performance 
parameters  that  serve  as  goals  or  constraints  for  system  performance.  MPT  issues  at  this  stage  are 
usually  represented  as  manpower  spaces  per  system,  as  support  environment  constraints,  or  as 
reliability  and  maintainability  (R&M)  system  goals. 
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2.  Assign  Functional  Allocation.  The  weapon  system  functionality  is  apportioned  into 
subsystem  capabilities.  For  example,  the  functional  requirements  of  system  payload,  range,  and 
speed  are  allocated  to  engine  thrust,  gross  airframe  weight,  weapon  system  delivery  capacity, 
landing  gear  load  requirements,  fuel  system  requirements,  and  so  on.  This  functional  allocation 
process  is  taken  down  to  a  level  where  either  existing  components  to  suit  the  function  ''an  be 
identified,  or  the  component  that  needs  to  be  developed  can  be  specified  in  terms  of  its  technology, 
size,  risk,  cost,  and  logistics  burden.  The  resulting  system  description  is  intended  to  give 
management  a  clear  idea  of  how  the  final  product  will  behave.  At  this  point,  allocated  MPT  issues 
are  usually  restricted  to  equipment  R&M  parameters.  Manpower  spaces  per  system  are  not 
allocated  down  to  specific  subsystems  or  components.  The  allocated  system  functional  baseline 
that  results  is  the  subject  of  the  Preliminary  Design  Review  (PDR),  an  important  prelude  to  system 
hardware  design. 

3.  Design  and  Integrate  Subsystems.  The  system  functional  descriptions  are  translated  into 
real  hardware  designs.  For  example,  an  oleo  strut  is  identified  or  designed  to  absorb  the  projected 
landing  gear  loads.  MPT  issues  are  still  bound  up  in  equipment  R&M  projections.  System 
considerations  are  now  calculable  from  the  predicted  R&M  characteristics  and  the  projected  logistics 
support  environment.  The  design  baseline  system  is  evaluated  at  the  Critical  Design  Review  (CDR) 
that  precedes  hardware  fabrication  and  assembly. 

4.  Evaluate  System  Performance.  The  ability  of  the  system  to  perform  its  required  function 
is  tested.  MPT  requirements  are  compressed  into  manpower  metrics  and  they  are  computed  using 
measured  R&M  characteristics  or  maintenance  data  on  fielded  comparable  systems 

5.  Reconsider  System  Specification.  The  functional  requirements  are  continually  reviewed 
throughout  the  weapon  system's  fielded  life  to  take  account  of  continual  changes  in  the  mission 
requirements,  the  threat,  and  available  technology.  This  ongoing  review  process  produces 
numerous  Engineering.Change  Proposals  (ECP:).  Occasionally  it  leads  to  a  complete  redesign. 

The  SE  approach  to  weapon  system  technical  management  marries  the  definition, 
development,  and  integration  of  hardware  to  specific  sets  of  operational  requirements.  Well- 
understood  relationships  between  the  weapon  system's  component  parts  and  the  expected  behavior 
of  the  overall  weapon  system,  such  as  that  among  weight,  thrust,  and  speed,  contribute  to  the 
success  of  this  orderly  development  strategy  in  tvM  way  .  First,  knowledge  of  the  part-to-whole 
relationships  permits  greater  engineering  and  management  control.  The  part-to-whole  relationships 
allow  specification  of  attainable  design  goals  for  the  subsystems,  and  for  these  to  meet  system 


3 


operational  requirements.  Second,  knowledge  of  the  part-to-whole  relationships  permits  design 
flexibility  and  innovation.  That  is,  knowledge  of  these  relationships  allows  trade-offs  and 
adjustments  to  particular  subsystem  attributes  during  the  system  design  in  response  to  new 
requirements  and  new  opportunities  that  may  arise  during  design. 

At  present,  logistics  concerns  beyond  equipment  R&M  do  not  fit  readily  within  the  SE 
approach.  This  is  because  many  individual  elements  of  a  weapon  system's  logistics  profile, 
particularly  the  MPT  elements,  are  not  easily  relatable  to  the  design  characteristics  of  specific 
systems.  Rather,  they  belong  to  the  broader  requirements  supporting  several  constituent  systems. 
For  example,  the  problem  of  allocating  manpower  with  R&M  to  subsystems  does  not  work  well 
because  maintenance  career  fields  do  not  map  precisely  to  the  standard  equipment  decomposition 
arrangement.  Most  Aii  Force  Specialties  (AFSs)  deal  with  more  than  a  single  system,  and  many 
systems  require  multiple  AFSs.  The  potentially  relevant  part-to-whole  relationships,  such  as  the 
test  and  support  equipment  burden  for  individual  systems,  are  not  well  understood  or  easily  arrived 
at  either.  Other  examples  are  found  in  the  indirect  linkage  between  maintenance  manpower  and 
equipment  R&M  characteristics,  and  the  lack  of  prescriptive  relationships  that  might  link 
maintenance  technician  skill  level  with  specific  equipment  design  characteristics. 

The  best  understood-or,  at  any  rate,  best  accepted-interaction  between  mission  capability 
and  logistics  generally  is  through  the  design  interface  of  R&M.  The  operational  relationship  to 
R&M  is  clear.  The  less  often  equipment  breaks  (R),  and  the  faster  it  is  repaired  (M),  the  more 
capable  the  system  will  be.  All  commonly  used  R&M  metrics  are  additive  and  well  behaved,  and 
arithmetic  using  them  is  straightforward.  Hence,  R&M  metrics  are  readily  used  by  design 
engineers.  But  much  is  missing.  For  beneath  this  relationship  between  R&M  and  operational 
capability  is  a  complex  set  of  relationships  between  R&M,  availability,  MPT,  and  support  costs 
that  needs  to  be  considered  in  economically  fielding  a  new  system.  Current  practice  entails  the  early 
development  of  acceptable  R&M  design  goals  which  are  followed  during  weapon  system 
development  without  much  regard  for  the  total  logistics-oriented  MPT  resource  impacts. 

The  credibility  and  effectiveness  of  R&M  design  constraining  is  reduced  by  (a)  inaccurate 
reliability  estimates;  (b)  unknown  effects  of  operational  policy;  (c)  overreliance  on  standard 
removal  and  replacement  times,  which  can  greatly  understate  the  difficulty  of  the  maintainer’s  actual 
task;  (d)  maintainability  estimates  requiring  previously  developed  comparable  systems  or  the 
construction  of  a  prototype  for  testing;  (e)  poorly  nderstood  relationships  between  equipment 
complexity  and  MPT  support  impacts  during  subsystem  design;  and  (f)  the  high  schedule  impact, 
program  risk,  and  cost  of  a  redesign  activity.  Experience  shows  that  only  large  deficiencies  warrant 


4 


the  level  of  program  risk  that  would  be  introduced  by  a  redesign  slippage.  R&M  shortfalls  may  be 
perceived  as  more  safely  handled  by  scaling  up  the  out-year  support  costs.  In  this  way,  reliability 
deficits,  if  they  appear,  will  be  spread  over  the  entire  weapon  system  life  cycle. 

Hand-in-hand  with  the  lack  of  simple,  direct  relationships  between  logistics  and  operational 
capability  assessment  is  the  difficulty  in  exploiting  the  trade-offs  in  logistics  part-to-whole 
relationships.  System  R&M  parameters,  which  are  easily  calculated,  are  typically  used  for  routine 
impact  evaluation  instead  of  the  more  laborious  and  compicated  Manpower  by  AFS  statistic. 
Consequently,  MPT  issues  are  often  handled  arbitrarily  and  implicitly,  or  treated  as  mere  planning 
problems.  The  ability  to  set  system  goals  and  constraints,  manage  system  development  accurately 
and  flexibly,  and  perform  trade-offs  within  the  larger  logistic  domain,  including  MPT,  requires  a 
better  explication  of  the  relationships  between  the  design  interface  for  R&M  and  the  total  logistics 
burden.  Here  is  the  objective  of  TDSTL. 

II.  MPT/SE  PROCESS  MODEL 

The  MPT/SE  Process  Model  proposed  here  is  simply  a  list  of  MPT-related  tasks.  This  list 
is  the  basis  for  the  companion  MPT/SE  Data  Model.  The  Process  Model  was  developed  in  a  top- 
down  fashion  but  without  the  aid  of  a  formal  task  decomposition  procedure  such  as  IDEF  (Mayer  & 
Young,  1988a).  MPT  activities  are  listed  under  their  appropriate  stage  in  the  SE  activity.  Temporal 
relationships  among  the  tasks  are  not  specified  because  we  wanted  to  retain  maximum  flexibility  in 
evaluating  or  developing  alternative  strategies  for  MPT  analysis.  The  IDEF  approach  was  deemed 
unnecessary  for  this  purpose.  However,  understanding  of  the  Data  Model  might  be  enhanced  by 
graphic  representation  using  some  IDEF1  modeling  conventions.  (See  Figures  3  &  4  in  Section 
III). 


Defining  the  MPT  Domain 

The  primary  use  of  the  MPT/SE  Process  Model  is  to  define  what  the  MPT  domain 
encompasses.  The  working  definition  of  the  MPT  domain  for  this  purpose  includes  maintenance 
manpower  estimation,  Air  Force  Specialty  (AFS)  job  design,  and  training  resource  identification 
for  an  individual  weapon  system  and  for  its  support  equipment.  MPT  for  this  purpose  excludes 
those  issues  falling  exclusively  within  the  design  interface  disciplines  of  human  factors  engineering 
(IIFE)  and  reliability  engineering.  These  are  related  fields  that  provide  valuable  MPT  parameters. 
Unfortunately,  the  boundary  lines  are  not  always  as  clear  or  as  clean  as  we  might  like.  For  example, 
HFE  task  time  estimating  techniques  are  not  MPT,  but  the  task  time  data  are  within  the  MPT 
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domain.  Likewise,  the  particular  technique  used  to  estimate  reliability  for  a  new  cc  ..iponer.;  is 
outside  the  MPT  domain,  but  the  reliability  estimate  itself  is  an  important  input  to  the  MPT  domain. 
Also  excluded  from  TDSTL  are  issues  having  to  do  with  wider  force  management.  We  do  not  deal 
with  sustainment  of  career  fields,  assignment  policy,  grade  structure,  accession  testing,  cross 
training,  training  development,  MAJCOM  manpower  allocation,  and  other  matters  belonging  to  the 
Air  Force  MPT  management  system  at  the  macro  level.  In  other  words,  our  scope  specifically 
excludes  what  might  be  called  MPT  in  the  large .  We  include  only  MPT  in  the  small  within  TDSTL. 

Other  excluded  activities  within  the  workaday  MPT  domain  are  the  development  of  specific 
reporting  and  planning  documentation,  and  training  development  in  the  form  of  Instructional 
System  Development,  or  ISD.  The  various  MPT  reporting  and  documentation  requirements, 
important  though  they  are,  were  excluded  because  the  focus  of  TDSTL  is  the  information  and 
analysis  processes  within  SE,  not  the  WSAP  or  the  System  Program  Office  (SPO)  communications 
problem.  These  are  elaborately  detailed  elsewhere.3 

A  comment  about  the  real  world  we  have  observed  is  needed  here.  The  position  of  MPT 
within  the  Integrated  Logistics  Support  (ILS)  community  does  not  seem  to  allow  a  clean  separation 
of  MPT  into  a  separate  planning  activity  or  career  path.  Manpower  estimates  pervade  almost  all 
aspects  of  ILS  analysis:  training,  facilities,  base  support,  transportation,  support  equipment,  and, 
of  course,  prime  equipment  maintenance.  Moreover,  manpower  can,  to  a  certain  extent,  be 
substituted  for  other  resources  such  as  spare  parts  to  achieve  higher  sortie  rates.  For  both  practical 
and  technical  reasons,  an  examination  of  MPT  issues  in  an  actual  acquisition  program  would  do 
well  to  stay  within  the  established  ILS  framework.  The  real  world  of  SPO-level  logistics  makes  no 
distinction  between  the  MPT  specialist  and  the  general  logistician.  Hence,  the  distinction  between 
MPT  and  logistics  analysis  made  here  is  an  arbitrary  and  somewhat  artificial  one,  a  demarcation  laid 
down  solely  to  scope  the  effort  and  to  sharpen  the  issues.  But  MPT  is  inextricably  linked  with  ILS 
in  the  real  world.  It  fits  within  reliability  engineering,  maintenance  resource  plann;ng,  and  other 
logistics  elements. 

Table  1  presents  the  proposed  MPT/SE  Process  Model.  Appendix  A  contains  descriptions 
of  the  identified  tasks.  The  analytic  activities  for  MPT  can  be  summarized  as  (a)  assembling 
operational  and  system  R&M  information;  (b)  computing  manpower  by  AFS;  and  (c)  estimating 
parameters  that  require  manpower  in  their  formulation,  such  as  training  and  personnel  requirements. 

3  See,  for  example,  the  MPT  Integration  System  (MPTIS)  proposal  by  Akman  (1987)  and  the  Army  MANPRINT 
program  documents.  Among  its  other  problems,  MPT  is  preoccupied  with  details  of  the  acquisition  process  rather 
than  details  of  its  analytic  process. 
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Table  1.  MPT/SE  Process  Model 


1.0 


2.0 


3.0 


4.0 


5.0 


Develop  functional  description. 

1 . 1  Identify  operational  requirements. 

1.2  Propose/develop  comparable  system. 

1 .3  Perform  comparability  analysis. 

1.3.1  Compute  comparable  manpov/er. 

1 .3.2  Compute  comparable  training  requirements. 

1.3.3  Compute  comparable  accession  requirements. 

Assign  functional  allocation. 

2. 1  Update  operational  requirements. 

2.2  Allocate  MPT  MOMs  to  subsystems. 

2.3  Estimate  MPT  MOMs  from  functionally  allocated  baseline  system. 

2.3. 1  Compute  allocated  manpower. 

2.3.2  Compute  allocated  training  requirements. 

2.3.3  Compute  allocated  accession  requirements. 

Design  and  integrate  subsystems. 

3 . 1  Update  operational  requirements. 

3 . 2  Estimate  MPT  MOMs  from  subsystem  design. 

3.2.1  Compute  predicted  manpower. 

3.2.2  Compute  predicted  training  requirements. 

3.2.3  Compute  predicted  accessions  requirement. 

Evaluate  system  performance. 

4. 1  Update  operational  requirements. 

4.2  Estimate  MPT  MOMs  from  field  experience  data. 

4.2. 1  Compute  predicted  manpower. 

4.2.2  Compute  predicted  training  requirements. 

4.2.3  Compute  predicted  accessions  equipment. 

Reconsider  system  specification. 

5. 1  Update  operation  parameters. 

5.2  Propose  and  evaluate  revised  system  support  concepts. 

5.3  Evaluate  candidate  system  upgrades. 


A  very  simple  system  data  flow  is  evident  in  this  model.  Primary  logistics  characteristics  are  the 
inputs  to  the  Compute  Manpower  analysis  activity.  Manpower  by  AFS  is  the  output  from  this  node. 

It  becomes  a  major  part  of  the  input  to  the  training  and  personnel  analysis  nodes.  Implicit  in  the 
model  is  the  interactive  use  of  MPT  analysis  in  setting  system  performance  requirements  or 
monitoring  system  development  and  performance  at  each  step  of  the  SE  process. 

MPT  Within  System  Development 

MPT  analysis  within  the  earliest  phase  of  system  development  should  consist  mainly  of  the  # 

identification  and  advocacy  of  logistics  requirements  and  technical  approaches  that  would  allow 
tangible  improvements  in  net  supportability  of  the  new  system  over  existing  systems.  This  search 
for  efficient  logistics  alternatives  is  normally  grounded  in  comparability  analysis  (Tetmeyer,  1971, 

Tetmeyer  &  Moody,  1974).  Coupled  with  this  proactive  search,  generally,  is  an  analysis  of  the 
sortie  generation  or  operational  availability  impact  of  the  emerging  system's  projected  logistics 
support  system.  The  distinction  between  MPT  and  other  logistic  elements  at  this  point  is  somewhat 
arbitrary  since  sortie  generation  assumes  an  array  of  interrelating  resources,  including  trained  and 
experienced  manpower,  which  must  be  managed  in  an  integrated  fashion. 

Figure  2,  from  the  Air  Force  Logistics  Support  Analysis  Primer  (AFLCP  800-17),  depicts 
the  design  influence  emphasis  of  the  early  logistics  analysis.  Many  other  depictions  of  this  process 
exist,  but  this  is  the  clearest  and  simplest  one  we  have  found.  The  figure  also  shows  the 
subsequent  shift  in  focus  to  resource  planning  ("ID  Resources")  that  characterizes  logistics  analysis 
as  system  development  proceeds.  In  essence,  first  influence  design,  then  plan  the  support. 

The  TDSTL  MPT  Process  and  Data  Models  are  based  upon  these  simple,  basic  ideas.  But 
the  models  for  MPT  we  expect  to  use  will  need  to  be  altered  where  they  fall  outside  of  "as  is" 
practice.  For  example,  one  candidate  MPT  model,  the  Small  Unit  Maintenance  Manpower  Analysis 
(SUMMA)  model  (Miller,  1988;  Boyle,  1989)  combines  early  manpower  and  AFS  structure 
analysis  into  a  single  optimization  problem.  But  the  SUMMA  model  departs  from  the  "as  is"  AFS 
policy  view.  That  is,  the  AFS  structure  for  a  new  system  is  customarily  copied  directly  from  the 
predecessor  system,  which  is  not  necessarily  the  comparable  system.  The  MPT  Data  and  Process 
Models  of  TDSTL  will  be  used  to  determine  whether  the  requisite  data  for  this  analysis  at  e  available 
at  the  point  that  deviation  from  standard  practice  is  proposed  (i.e.,  if  the  new  system  is  feasible)  and 
how  the  remaining  MPT  tasks  would  be  affected  by  the  change  in  procedure  (e.g.,  by  the  "to  be" 

AFS  policy). 
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Figure  2.  Role  of  LS A  in  Logistics  Design  and  Planning. 
III.  MPT/SE  DATA  MODEL 


The  proposed  MPT/SE  Data  Model  (Appendix  B)  was  created  by  First  developing  a  tentative 
list  of  the  data  elements  applicable  to  the  MPT/SE  Process  Model.  Then  major  logistics  data  sources 
were  searched  for  relevant  inputs.  These  were  the  Logistics  Support  Analysis  Record  (LSAR)  and 
the  Logistics  Composite  Model  (LCOM).  Data  definitions  were  searched  for  relevant  MPT  data 
elements.  These  elements  were  used  to  update  the  MPT/SE  Data  Model.  Lists  of  LSA  and  LCOM 
data  are  presented  in  Appendices  C  and  D,  respectively.  The  detailed  MPT/SE  Data  Model  is 
presented  in  Appendix  E. 

One  benefit  of  the  Data  Model  is  to  increase  the  precision  with  which  one  may  talk  about  the 
MPT  process.  This  discipline  will  be  useful  in  comparing  and  planning  development  of  MPT  and 
logistics  analysis  tools.  The  immediate  use  of  the  MPT/SE  Data  Model  is  to  provide  a  basis  for 
defining  practical  Measures  of  Merit  (MOMs)  for  use  as  control  variables  within  the  SE  process. 
The  Process  and  Data  models  are  also  used  to  analyze  two  MPT  development  efforts,  the  SUMMA 
and  HARDMAN  III,  as  candidates  for  MPT  analysis  within  TDSTL.  The  IMACAD  effort  will  use 
the  MPT  Data  Model  to  develop  a  manpower  analysis  tool  for  use  throughout  the  SE  process.  The 
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fo!low-on  TDSTL  II  effort  will  use  the  Data  Model  to  estimate  the  precision  with  which  various 
MPT  parameter  estimates  can  be  made  during  the  SE  process  and  to  recommend  algorithms  for 
implementation  in  logistics  analysis  tools. 

The  MPT  Data  Model  is  a  list  of  the  data  routinely  used  and  transformed  by  the  MPT  analyst 
during  each  phase  of  the  SE  process.  The  data  classes  tend  to  reappear  from  one  level  of  the  SE 
process  to  the  next.  The  basic  problem  for  MPT  analysis  in  this  context  is  to  predict  system 
operational  and  logistics  performance  from  design  parameters  and  system  specifications.  This 
problem  is  essentially  unchanged  whether  the  system  is  a  tentative  alternative  design  being  assessed 
for  MPT  supportability  early  in  design  or  a  fielded  system  for  which  a  manpower  study  is  being 
performed.  As  design  moves  along,  the  accuracy  and  detail  of  the  input  data  increase,  but  the 
analytic  problem  is  more  or  less  unchanged  throughout. 

As  noted,  the  MPT  Data  Model  was  developed  by  integrating  LSA  (MIL-STD  1388- 1 A  and 
MIL-STD-1388-2A)  requirements  with  LCOM  data  requirements  (Dengler,  1981;  Drake  & 
Wieland,  1982).  This  is  substantially  the  same  approach  used  in  the  most  recent  study  of  the  WSAP 
to  locate  and  evaluate  MPT-relevant  tools  and  data  bases.4  Notably  lacking  in  these  two  data 
environments  are  detailed  training  material  requirements  estimation  and  development;  planning  and 
predicting  the  requirements  for  maintenance  technical  orders  and  job  aids;  and  detailed  cost 
modeling  data.  Recent  alterations  to  the  LCOM  structure  and  the  Unified  Life  Cycle  Engineering 
project  (Brei  et  al.,  1988)  partially  address  these  areas. 

Logistics  Support  Analysis  (LSA)  Data 

LSA  is  the  established  process  within  the  Integrated  Logistics  Support  (ILS)  program  that 
incorporates  all  aspects  of  System  Engineering.  ILS  is,  in  fact,  the  means  by  which  Systems 
Engineering  for  logistics  supportability  is  implemented  in  the  Air  Force.  The  LSA  provides  a 
comprehensive  model  of  all  logistics  trade  studies,  and  the  LSAR  enumerates  most  of  the  data 
elements  applicable  to  MPT  in  the  SE  process.  For  this  reason,  LSAR  should  be  thought  of  as  the 
basic  roadmap  for  MPT  analysis  development  within  the  SE  process. 

The  LSAR  is  organized  into  Data  Records,  which  are  further  subdivided  into  cards,  and 
further  subdivided  into  blocks.  Cards  01  -  06  are  identification  cards  on  A  -  C  records.  LSAR  is 
organized  by  the  LSA  control  number  and  provides  cross-referencing  to  planning  documentation, 

4  See  Rossmcisscl  et  a!.  (1990,  Draft).  "MPTS  in  the  WSAP:  Analysis  of  Manpower,  Personnel,  Training  & 

Safety  During  the  Acquisition  of  Air  Force  Systems:  Requirements  and  Capabilities." 
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manufacturer's  part  numbers,  federal  supply  code  for  manufacturers,  work  unit  codes,  and  other 
links  to  technical  data  or  government  identification  schemes.  These  technical  details  have  been 
avoided  in  the  development  of  the  MPT  data  model.  An  LSAR/MPT  data  translation  table  is 
presented  in  Appendix  C. 

The  important  SE  distinction  among  "Comparable,"  "Allocated,"  "Predicted,"  and 
"Measured"  MPT  parameters  is  imperfectly  made  in  the  LSAR.  Only  the  R&M  parameters  are 
included  in  this.  In  particular,  the  B  record  distinguishes  among  comparability,  allocated,  predicted, 
and  measured  R&M  characteristics,  and  the  D1  record  distinguishes  between  predicted  and 
measured  mean  man-hours  per  AFS.  This  information  was  presumably  included  in  LSA  for  its 
usefulness  in  interpreting  the  qualified  data.  Inasmuch  as  the  LSAR  data  are  viewed  as  an  evolving- 
-as  opposed  to  an  archival-record  about  an  emerging  system,  this  is  a  reasonable  inclusion.  The 
logical  next  step  in  interpreting  the  historical  data  is  to  develop  a  quantitative  estimate  of  the 
uncertainty  of  the  various  types  of  system  MPT  performance  estimators. 

The  card  format  of  the  LSAR  data  is  not  very  compact.  Multiple  locations  are  noted  for 
identifiers  and  important  data  items.  Moreover,  much  of  the  data  on  the  forms  can  be  derived  from 
other  elements,  for  example,  only  two  of  "crew  size,"  "total  man-hours,"  and  "task  duration"  are 
required  to  compute  the  third  parameter,  but  LSAR  data  will  typically  require  all  three  data  elements. 
The  cross-referencing  against  the  MPT/SE  data  model  does  not  attempt  to  identify  these  overlapping 
requirements  or  data  dependencies. 

But  not  all  SE/MPT  data  applicable  to  TDSTL  are  inherent  in  the  LSAR  format.  Missing 
from  LSAR  data  are  manpower  utilization,  general  training  requirements,  and  personnel-oriented 
parameters  of  "shop"  supervision,  non-chargeable  maintenance  man-hours,  training,  and  AFS 
turnover  rates. 


LCOM  Data 

LCOM  is  a  maintenance  simulation  system  developed  in  the  mid-1960s  by  the  Rand 
Corporation.  LCOM  is  used  to  simulate  the  relationships  among  resources  (airplanes,  manpower , 
support  equipment,  and  parts)  and  sortie  generation  capability.  Its  use  in  manpower  allocation  is 
institutionalized  within  the  Air  Force  by  regulation  and  by  the  existence  of  dedicated  organizations 
and  a  distinct  career  field  to  analyze  air  base  operations  within  each  Major  Command  (MAJCOM), 
Air  Force  Logistics  Command  (AFLC),  and  acquisition  organization.  LCOM  essentials  are 
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explained  in  Boyle  (1990).  LCOM  data  bases  describe  maintenance  task  requirements  in  terms  of 
task  networks.  These  data  bases  often  provide  a  rich  source  of  primary  information  supporting 
MPT  analysis,  as  shown  in  Appendix  C. 

Task  demand  rate  is  modeled  in  LCOM  by  first  setting  a  per-sortie  failure  rate  for  each  of  an 
aircraft's  subsystems  and  then  allocating  this  failure  rate  among  the  subsystem's  components  in  a 
probabilistic  fashion.  This  means  that  the  failure  mechanism  for  a  Shop  Replaceable  Unit  (SRU), 
usually  described  in  terms  of  failures  per  operating  hour,  is  modeled  by  calculating  and  recording 
the  per-sortie  failure  rate  for  the  SRU's  subsystem  and  calculating  the  conditional  probability  that 
this  particular  SRU  will  fail,  given  a  failure  of  the  subsystem.  The  LCOM  Data  Preparation 
Subsystem  converts  failure  data  on  existing  Air  Force  systems  into  LCOM  format.  Corresponding 
pre-processor  programs  also  are  available  to  translate  LRU  data  into  SRU  failure  rates.  'Phis  very 
detailed  modeling  capability  of  LCOM  is  not  yet  included  in  the  TDSTL  Data  Model. 

A  detailed  means  to  represent  configurations  for  different  missions,  the  reconfiguration 
activity,  and  the  concomitant  aircraft  scheduling  activity  is  a  feature  of  LCOM.  This  facility  is 
valuable  in  detailed  examinations  of  the  aircraft  turnaround  problem  with  LCOM,  but  it  is  of  no 
value  for  MPT  beyond  what  task  loading  the  reconfiguration  tasks  themselves  entail. 

Figure  3  presents  a  broad  view  of  the  MPT  data  flow  within  the  larger  logistic  domain.  The 
most  salient  features  are  the  relative  simplicity  of  the  MPT  data  flow  and  the  central  importance  of 
the  "Manpower  by  AFS"  statistic.  This  statistic  is  sensitive  to  the  manner  in  which  tasks  are 
allocated  to  AFSs.  Specifically,  if  AFSs  are  defined  broadly,  fewer  people  will  be  required;  if 
narrowly,  more  people.  The  trade-offs  between  broad  and  narrow  AFS  definition  are  the  subject  of 
the  SUMMA  MPT  model  (Boyle,  1989). 

Reliability  is  given  in  terms  of  expected  operation  hours  or  cycles  to  failure  (with  Poisson 
failure  distributions  for  unscheduled  maintenance)  or  constant  time  intervals  (for  scheduled 
maintenance).  Any  scheme  to  perform  manpower  estimation  needs  to  translate  from  the  operational 
time  reference  to  the  24-hour  maintenance  environment.  Thus,  the  "Task  Demand"  pipeline  is 
introduced  into  the  model  to  simplify  the  graphic  representation  of  the  data  model.  Table  2  provides 
information  on  the  data  transformation  required  of  routinely  presented  maintenance  demand  data. 

Figure  4  presents  the  data  flow  according  to  the  "Comparable,"  "Allocated,"  "Predicted," 
and  "Measured"  distinction  used  in  reliability  prediction.  It  should  be.  noted  that  there  is  no 
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Figure  3.  MPT  Analysis  Framework  Design  and  Planning. 


Table  2.  Reliability  to  Task  Demand  Translation 


Metric: 

Per/Sortie 

Time/Sortie 

Cycles  Calendar  Time 

Maintenance 

Unscheduled  Maintenance 

X 

X 

X 

Scheduled  Maintenance 

Mission  Profile  Change 

X 

RCM  (Preventative) 

X 

X 

X 

X 

Inspection 

Post-Flight 

X 

Pre-Flight 

X 

Daily 

X 

Periodic 

X 

X 

X 

X 
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"Measured"  manpower.  Field  manpower  is  really  "Predicted"  since  it  is  allocated  against  a  set  of 
hypothetical  conditions. 

Of  particular  interest  for  TDSTL  are  the  analytical  possibilities  available  for  computing 
manpower  from  the  more  fundamental  parameters.  Three  approaches  are  in  general  use  in  the  Air 
Force  for  this  purpose:  Monte  Carlo  simulation  (i.e.,  LCOM),  analytic  queuing  modeling,  and  the 
R&M  practice  of  multiplying  task  time  by  reliability  and  dividing  by  a  manpower  utilization  factor  to 
get  manpower.  The  Air  Force  standard  approach  is  LCOM.  The  complexity  of  maintenance  demand 
argues  for  the  simulation  approach  since  some  of  the  simplifications  required  to  use  the  analytic 
queuing  approaches  may  not  provide  sufficiently  accurate  answers  for  all  purposes.  On  the  other 
hand,  a  simulation  approach  is  more  time  consuming  and  requires  greater  analyst  sophistication. 
Since  Manpower  byAFS  is  the  critical  measure  for  the  MPT  domain,  the  relative  accuracy  of  these 
three  approaches  should  be  determined  in  a  systematic  way.  This  is  planned  as  part  of  the  follow-on 
TDSTL  effort. 

Several  data  elements  not  included  in  the  MPT  data  model  bear  mention.  Most  notable  is  the 
"utilization"  statistic.  This  statistic  is  the  proportion  of  time  that  maintenance  technicians  are  usefully 
employed  in  maintenance.  Some  inactive  time  is  inevitable  in  an  unscheduled  maintenance 
environment.  The  statistic  is  often  reported  as  a  MOM  in  both  operational  and  acquisition  circles. 
The  figure  can  be  ambiguous  and  misleading,  though,  because  higher  manpower  utilization  rates 
can  reflect  lower  availability,  more  efficient  job  structuring,  lower  manpower,  or  more  efficient 
maintenance  scheduling. 

The  only  practical  value  of  manpower  utilization  as  a  MOM  for  TDSTL  is  during  its  use  in 
LCOM  manpower  studies  to  help  select  where  to  adjust  manpower  when  manpower  is  being 
constrained  (i.e.,  when  the  minimal  manpower  required  to  achieve  a  given  sortie  rate  is  being 
determined),  and  as  a  scaling  factor  in  R&M  studies  to  convert  maintenance  manhours  per  flight 
hour  to  manpower  slots.  Manpower  utilization  is  used  in  the  first  case  to  approximate  marginal 
improvement  in  sortie  generation.  This  is  not  readily  computed,  to  be  sure,  and  thus  has  very 
limited  analytical  use.  This  second  use  of  the  utilization  statistic  is  equally  tenuous.  Thus,  utilization 
was  excluded  from  the  MPT  Data  Model.  The  other  major  omissions  are  task  analysis  data.  These 
data  provide  much  of  the  basis  for  safety  analysis,  as  well  as  training  material  and  technical  order 
development.  But  from  an  MPT  analysis  perspective,  it  is  the  C  Record  level  of  analysis,  or 
subsystem  R&M  data,  that  forms  the  baseline  for  TDSTL.  The  detailed  task  analysis  data  from 
Record  D  simply  arrive  too  late  in  the  SE  process  to  be  of  practical  use  for  design  influence. 
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IV.  MEASURES  OF  MERIT  (MOMs) 


Purpose  and  Selection 

The  purpose  of  the  evaluation  of  MPT  MOMs  is  to  identify  and  suggest  MPT  parameters  for 
use  as  control  variables  within  the  SE  process.  As  noted,  MPT  parameters  are  more  encompassing 
than  straight  R&M  or  support  environment  requirements/prohibitions,  but  they  are  not  always 
readily  or  unimpeachably  calculable.  Criteria  for  candidate  MOM  nomination  were  based  solely  on 
pragmatics.  A  MOM  had  to  be  present  (or  calculable)  within  the  MPT  Data  Model,  or  used  in 
established  programs,  or  identified  in  previous  surveys  on  the  subject  to  be  considered. 

Air  Force  documents  surveyed  for  possible  MPT  MOMs  consisted  of  two  recent  reviews 
(Naval  Weapons  Center,  1986;  Delane,  1989),  supportability  direction,  and  the  LSAR  and  LCOM 
data  definitions.  Recommendations  of  previous  surveys  were  restricted  to  maintainability  in  the 
form  of  average  man-hours  per  maintenance  action  or  flight  hour. 

To  determine  what  MOMs  are  in  actual  use  eariy  in  the  acquisition  process,  we  reviewed 
early  program  documentation  for  the  Advanced  Theater  Transport  (ATT)  and  the  Special  Operations 
Forces  (SOF)  aircraft  efforts.  ATT  documentation  consisted  of  the  draft  Statement  of  Need  (SON) 
and  requirements  coordination  matrix.  Pre-concept  trade  studies  from  McDonnell-Douglas,  Boeing, 
and  Lockheed  were  also  examined.  Draft  Statement  of  Operational  Requirements  Document 
(SORD)  and  Statement  of  Work  (SOW)  documents  for  a  second  round  of  pre-concept  studies  were 
also  examined.  SOF  documentation  consisted  of  the  Draft  SON  and  programmatic  information 
being  developed  by  Air  Force  Wright  Aeronautical  Laboratory/Flight  Dynamics  (AFWAL/FG)  for 
eventual  incorporation  into  a  Procurement  Decision  Package  (PDP)  or  SOW. 

The  ATT  and  SOF  efforts  contained  maintenance  slots  per  aircraft,  support  equipment,  and 
deployment  burden  goals  in  the  SONs;  hard  logistics  requirements  of  direct  impact  on  manpower 
were  restricted  to  R&M  and  Precision  Measurement  Equipment  (PME)  requirements.  The 
manpower  trade  studies  used  the  usual  maintenance  man-hours  per  flight  hour  times  task  time 
approach.  This  is  not  to  say  that  no  other  MOMs  applicable  to  MPT  could  have  been  used,  or 
should  have  been  used.  It  is  only  to  say  that  these  are  the  MOMs  the  real  world  uses  now. 
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Candidate  MOMs 


This  leads  to  a  limited  set  of  candidate  MOMs  to  be  used  as  control  variables,  singly  or  in 
combination,  within  the  SE  process  for  TDSTL  development  The  candidate  MOMs  are: 

Maintenance  Tasks  by  Subsystem 
Reliability  by  Subsystem 
Maintenance  Task  Times 
Maintenance  Crew  Size  by  Task 
Manpower  by  AFS 

Manpower  Slots  per  Primary  Assigned  Aircraft  (PAA) 

AFS  Structure 

System  Training  Requirements 
Required  Accessions  by  AFS  per  Year 

Maintenance  Tasks  bv  Subsystem 

The  maintenance  concept  can  restrict  the  system  under  development  by  mandating  a  level  of 
repair  on  equipment.  The  restriction  of  avionics  equipment  maintenance  to  on-equipment  and  depot 
level  maintenance  is  a  good  example  of  this.  Restrictions  of  this  sort  may  not  always  be  appropriate 
since  it  is  generally  an  item's  reliability  that  drives  its  repair  level.  In  this  case,  it  would  seem  best 
to  control  reliability  directly  as  opposed  to  controlling  only  its  implications.  If  the  intention  of  a 
MOM  in  this  area  is  to  restrict  support  equipment,  test  stands,  and  so  on,  the  better  way  of  going 
about  it  would  be  to  apply  these  particular  constraints  straightforwardly.  If  the  intention  of 
restrictions  in  this  area  is  to  control  task  times  by  eliminating  lengthy  tasks,  such  as  in-place  repairs, 
distortions  to  the  maintenance  system  may  result.  The  cost  for  any  additions  to  the  logistics  pipeline 
is  shown  in  usually  expensive  spares  and  in  complex  back-shop  maintenance  equipment. 

Reliability  bv  Subsystem 

Reliability  is  of  such  paramount  importance  in  determining  both  logistics  considerations  and 
operational  effectiveness  that  is  is  hard  to  Find  a  drawback  to  applying  reliability  constraints  to  a 
system  under  development.  The  impact  of  reliability  on  manpower  should  be  monitored  during 
system  development,  though,  if  reliability  improvement  is  being  used  to  reduce  manpower. 
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Manpower  asymptotes  with  respect  to  increased  equipment  reliability.  Minimum  task  crew  size  and 
launch/recovery  work  begin  to  drive  manpower  requirements  rather  than  unscheduled  maintenance 
requirements  as  things  break  less  often. 

Maintenance  Task  Times 

Maintenance  task  time  requirements  are  fundamental  to  the  Air  Force  way  of  planning 
maintenance.  Particularly  important  are  aircraft  turnaround  times.  Task  times  should  not  be  used  as 
a  control  variable  without  the  associated  equipment  reliability  also  being  considered.  Therefore, 
maintenance  task  times  are  a  necessary  but  not  sufficient  requirement  for  optimum  MPT 
management  and  resource  control. 

Maintenance  Crew  Size  bv  Task 

Many  Air  Force  maintenance  tasks  require  several  technicians  working  in  concert  for 
completion.  This  is  called  the  minimum  task  crew  size.  From  the  MPT  standpoint,  this  increases 
manpower  requirements.  Inasmuch  as  crew  size  is  directed  by  military  standards  for  safety  and 
human  factors,  it  would  be  best  to  constrain  crew  size,  where  this  is  deemed  desirable,  by  directly 
addressing  safety  issues  through  engineering  task  design. 

ManpQ.wgr_by..A.FS. 

This  statistic  seems  to  provide  a  good  summaiy  of  the  system's  maintenance  burden  as  most 
of  the  recurring  system  cost  is  accrued  on  a  per-billet  basis:  wages,  training,  supervision,  facilities, 
and  so  on.  The  use  of  this  statistic  should  be  in  concert  with  a  target  AFS  structure  or  criteria  for 
redefining  the  existing  maintenance  structure.  The  major  drawback  with  Manpower  by  AFS  as  a 
control  variable  is  the  computational  strain.  The  official  manpower  requirement  will  usually  come 
from  an  LCOM  study.  Potentially  much  quicker  simulation  studies  are  now  possible  than  in  the 
days  of  punched  cards,  but  the  LCOM  technology  is  still  not  popular  among  R&M  ergineers.  They 
still  seem  to  prefer  the  maintenance  man-hours  times  reliability  method  for  its  computational 
simplicity.  Much  is  lost  through  this  expediency,  though,  as  the  LCOM  approach  is  apt  to  be  more 
accurate.  The  critical  question  here  is  how  accurate  the  manpower  estimate  needs  to  be.  This 
question  will  be  addressed  by  the  follow-on  TDSTL  study,  which  will  compare  LCOM  solutions  to 
solutions  provided  by  mathematical  models. 
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Manpower  Slots  per  PAA 


This  statistic  is  highly  dependent  upon  basing  concept,  as  was  shown  in  the  SUMMA  front- 
end  analysis  (Boyle,  1989).  Moreover,  this  statistic  is  normally  computed  only  for  base-level  (i.e., 
flightline  and  intermediate  shop)  maintenance  billets.  Thus,  the  drawback  of  this  MOM  is  the 
possibility  that  too  much  maintenance  will  be  relegated  to  the  depot  level,  resulting  in  a  highly 
deployable  system,  given  unlimited  spares,  but  an  overly  expensive  system  overall,  since 
manpower  costs  are  driven  to  the  depot,  which  is  normally  not  included  in  MPT  analysis. 

AFS  Structure 

Currently,  the  Air  Force  is  reorganizing  its  maintenance  AFSs  according  to  the  Rivet 
Workforce  suggestions.  The  basic  idea  is  to  combine,  merge,  or  otherwise  "restructure" 
maintenance  AFSs.  The  result  of  this  job  enlargement  is  a  reduction  of  unit  manpower  requirements 
and  a  more  flexible  workforce  for  combat  deployments.  AFS  structure  is  the  most  important  new 
variable  in  MPT  analysis  for  the  Air  Force.  Unfortunately,  AFS  definition  is  typically  not  controlled 
other  than  by  necessitating  additional  LSAR  justification  where  a  new  skill  is  thought  to  be 
required.  The  issue  of  AFS  restructuring  enters  into  problems  of  task  compatibility  and  training 
synergism.  The  interested  reader  is  referred  to  the  SUMMA  literature  (Miller,  1988;  Boyle,  1989) 
for  detailed  discussions  of  the  MPT  aspects  of  AFS  job  redefinition. 

System  Training  Requirements 

The  System  Training  Requirements  expand  upon  the  Manpower  by  AFS  statistic  by  allowing 
the  contractor  to  trade  off  one  AFS  policy  with  another  while  holding  training  constant.  Possible 
distortions  to  the  MPT  system  from  attempting  this  tactic  could  be  a  maintenance  workforce  which 
is  undermanned  in  the  more  complex  specialties,  that  is,  one  in  which  these  specialties  are  driven 
harder  than  the  less  training-intensive  AFSs. 

Required  Accessions  bv  AFS  Per  Year 

The  use  of  this  statistic  as  a  control  variable  would  drive  the  system  toward  favoring  AFSs 
that  turn  over  less  readily  or  require  less  time  to  become  fully  proficient.  This  could  be  a  valuable 
MOM  in  developing  an  optimum  MPT  workforce. 


19 


Flexibility  in  trading  off  one  concern  for  another  can  only  be  preserved  if  the  system  MPT 
MOMs  are  handled  within  an  integrated  analysis/tracking  framework.  Cost  analysis,  in  essence  a 
"design  to  cost"  strategy  within  a  constrained,  integrated  logistics  analysis  framework  (i.e.,  one  not 
including  number  of  systems  or  individual  system  capability  in  the  trades),  seems  the  most 
promising  framework  within  which  to  perform  trades  among  logistics  considerations,  including 
MPT. 

The  follow-on  TDSTL  will  examine  the  accuracy  with  which  these  statistics  can  be  computed 
and  measured,  and  the  extent  that  these,  or  some  subset  of  these,  MOMs  constitute  a  comprehensive 
set  of  control  variables. 

V.  SMALL  UNFf  MAINTENANCE  MANPOWER  ANALYSES  (SUMMA) 

This  section  and  the  following  use  the  MPT/SE  Process  and  Data  Models  to  evaluate  two 
important  MPT  analysis  tool  development  efforts  of  recent  years,  SUMMA  and  HARDMAN  III. 

Background 

The  first  effort  behind  the  Air  Force's  rekindled  interest  in  MPT  during  the  late  1980s  was 
the  AFHRL  SUMMA  effort.  The  project's  initial  purpose  was  to  provide  a  toot  to  evaluate  the 
impact  of  subsquadron-level  deployment  on  manpower  requirements  and  co  perform  a  sample 
analysis  using  this  system.  As  decentralized  logistic  system  performance  is  known  to  be  very 
sensitive  to  the  distributi-jn  of  limited  resources  such  as  spares,  tools,  and  manpower,  and  the 
optimal  reallocation  of  these  resources  only  improves  the  situation  slightly  over  an  ad-hoc  allocation 
policy,  the  SUMMA  effort  eventually  focused  on  the  AFS  definition  problem.  Naturally,  an  AFS 
restructuring  analysis  is  most  applicable  to  the  earliest  system  development  phases.  A  restructured 
workforce  would  require  three  to  five  years  preparation  prior  to  initial  operations  of  the  new  system 
with  Air  Force  personnel. 

The  central  manning  problem  in  small  unit  deployments  is  formally  classified  as  a  queuing 
problem.  In  general,  economy  of  scale  is  sacrificed  when  using  numerous  small  operations  in  these 
situations,  resulting  in  greater  system-wide  requirements  for  manpower  in  the  dispersed  situation 
than  in  the  centralized  one.  The  solution  to  the  problem  is  in  distributing  the  limited  manpower 
resource  in  such  a  way  that  MPT  costs  are  minimized  while  attaining  a  minimally  acceptable  system 
availability  rate.  There  are  three  plausible  strategies  to  solve  this  problem:  (a)  provide  more  overall 
manpower,  (b)  accept  lower  system  performance,  or  (c)  qualitatively  change  the  nature  of  the 
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manpower  resource  by  accepting  higher  training  and  personnel  costs  in  return  for  lower  overall 
numbers.  The  most  attractive  solution  is  the  third  solution,  expanding  the  breadth  of  the 
maintenance  technician's  job  responsibility.  In  other  words,  combine  the  AFSs  in  some  way. 

Thus,  the  SUMMA  effort  quickly  moved  to  address  the  interacting  MPT  effects  of  changing 
the  existing  AFS  policy.  In  an  SE  context,  the  SUMMA  analysis  strategy  is  to  decouple  task 
analysis  and  task  allocation  from  AFS  specification  early  in  the  Develop  Functional  Description 
phase  of  the  process.  In  essence,  this  changes  the  nature  of  comparability  analysis  from  nesting 
subsystems  within  AFSs  to  nesting  subsystem  responsibility  to  homogeneous  "task  bundles" 
which  are,  in  effect  new  AFSs  or  jobs.  Early  AFS  determination  is  replaced  by  an  AFS-free  task 
analysis,  with  AFSs  being  formed  as  "task  bundles"  grouped  by  an  integer  programming  strategy. 
Table  3  presents  the  SUMMA  in  the  context  of  the  SE/MPT  Process  and  Data  Models. 

Evaluation 

Within  the  framework  of  the  MPT/SE  process  model,  the  purpose  of  the  SUMMA  analysis 
is  to  replace  the  comparability  AFS-to-task  assignment  assumptions  with  an  early  task  analysis  to 
derive  comparable  and,  perhaps,  allocated  manpower  by  AFS.  The  new  MPT  data  requirements 
emerging  from  this  alteration  are  the  training  requirements  for  individual  tasks  and  for  whole  jobs. 

These  data  are  developed  within  the  initial  SUMMA  activity  by  dividing  each  AFS's  training 
into  a  common  and  AFS-specific  portion  and  deriving  a  system  of  prorating  the  AFS-specific 
portion  of  the  training. 

The  drawback  to  adopting  a  SUMMA  task/specialty  solution  stems  from  our  lack  of 
knowledge  and/or  lack  of  confidence  regarding  the  relationships  among  training  requirements,  job 
characteristics,  and  personnel  requirements  that  such  job  alteration  schemes  imply.  Specifically,  we 
have  no  way  of  knowing,  a  priori,  whether  the  AFSs  derived  from  a  SUMMA  analysis  are  feasible 
beyond  adapting  a  subject-matter  expert's  opinion.  The  current  AFS  structure  has  evolved  over  the 
post- World  War  II  era  in  response  to  constraints  on  personnel  quality,  high  turnover,  training  time, 
and  cost  limitations.  Essentially,  every  time  system  complexity  has  outgrown  an  AFS's 
performance  capability,  and  remedial  training  and  personnel  actions  have  not  ameliorated  the 
problem,  the  AFS  has  been  broken  out  into  new  AFSs  or  shreds,  each  being  more  specialized. 
Assuming  that  this  ad-hoc  procedure  has  been  done  in  a  fashion  that  approximates  optimality,  the 
current  AFS  structure  is  nearly  optimal  given  the  personnel  and  turnover  constraints  under  which 
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Table  3.  SUMMA  Processes  and  Data  Requirements 


1 .2  Propose/develop  comparable  system. 

INPUTS :  Technology  Type  by  Subsystem 

Sortie  Type 

OUTPUTS:  AFS/Subsystem  Assignment 

Reliability  by  Subsystem  (Comparable  Reliability) 
Maintenance  Tasks  by  Subsystem 
Maintenance  Task  Times 

1.2.1  Compute  training  burden  for  task  bundles. 

INPUTS:  AFS/Subsystem  Assignment 

Task  Descriptions 
Training  Requirements  by  AFS 
OUTPUTS:  Training  Requirements  by  Task  Bundle 

1.3  Perform  comparability  analysis. 

1.3.1  Compute  comparable  manpower. 

INPUTS :  Training  Requirements  by  Task  Bundle 

Reliability  by  Subsystem  (Comparable  Reliability) 
Support  Equipment 
Maintenance  Tasks  by  Subsystem 
Maintenance  Task  Times 
Maintenance  Crew  Size  by  Task 
OUTPUTS:  AFS/Subsystem  Assignment 

Comparability  Required  Manpower  by  AFS 

1.3.2  Compute  comparable  training  requirements.  (NO  CHANGE) 

INPUTS :  Comparability  Required  Manpower  by  AFS 

Training  Requirements  by  AFS 
OUTPUTS:  Comparability  System  Training  Requirements 

1.3.3  Compute  comparable  accessions  requirement.  (NO  CHANGE) 

INPUTS :  Comparability  Required  Manpower  by  AFS 

Comparability  System  Training  Requirements 
Historic  Personnel  Turnover  Rate  by  AFS 
OUTPUTS:  Comparability  Required  Accessions  by  AFS  per  year 
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the  system  operates.  Recombining  AFSs,  and  accepting  the  concomitant  larger  training  burden,  may 
look  optimal  on  paper  but  it  needs  to  consider  constraints  imposed  on  the  solution  by  personnel 
quality  and  the  impact  of  the  AFS  transformations  on  turnover. 

On  the  other  hand,  the  prorating  approach  to  training  requirements  estimation  used  in 
SUMMA  may  yield  non-additive  training  results  in  the  opposite  direction.  Training  synergism  may 
result  in  an  overall  reduction  in  specialty  training.  Further  progress  in  this  area  is  obviously 
unlikely  until  either  these  issues  are  addressed  empirically  or  a  SUMMA -based  AFS  solution  is  tried 
out  in  the  real  world.  Regrettably,  this  is  an  expensive  and  risky  undertaking. 

As  implemented,  the  AFS  structuring  facility  aside,  the  SUMMA  product  is  r  reasonably 
complete  MPT  comparability  analysis  tool  for  use  early  in  the  SE  process.  The  shortfall  with  the 
SUMMA  tool  for  later  SE  use,  when  accuracy  of  the  estimates  becomes  more  important,  is  the  lack 
of  evidence  supporting  the  system's  queuing  analysis  processor.  As  reported  in  Kirshner  and  Boyle 
(1990),  the  existing  SUMMA  system  is  shown  to  compare  fairly  well  with  LCOM  under  a  limited 
set  of  circumstances,  particularly  where  system  manning  is  driven  more  by  minimum  crew  size  than 
by  queuing  effects.  But  a  more  systematic  comparison  of  the  queuing  facility  against  known  results 
would  be  beneficial  in  establishing  the  robustness  of  this  facility. 

From  a  software  point  of  view,  the  SUMMA  model  can  be  viewed  as  a  set  of  auxiliary 
analysis  programs  for  use  within  the  LCOM  community.  The  AFS  structuring  facility  in  SUMMA 
is  designed  to  read  and  write  LCOM  data  sets.  Basing  the  system  upon  an  established  analysis 
environment  has  the  obvious  advantage  of  tying  into  a  body  of  expertise  and  potential  users.  The 
drawback  is  the  additional  training  required  for  first  use  of  the  SUMMA  analysis  tool.  And  LCOM 
itself  is  not  known  for  its  ease  of  use. 
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Figure  5.  SUMMA  Analysis  Sequence. 


The  Specialty  Structuring  System  (S^)  effort  is  an  extension  of  SUMMA.  The  main 
difference  is  that  the  S^  is  specifically  targeted  at  the  system  development  environment  while 
SUMMA  was  not.  It  is  also  intended  for  use  during  the  Develop  Functional  Description  phase  of 
the  SE  process,  although  extending  the  system  to  monitoring  parameters  during  the  later  phases  of 
the  SE  process  and  tying  the  data  reporting  to  the  requirements  of  the  WSAP  reporting  requirements 
are  planned. 


VI.  HARDMAN  HI 
Background 

In  the  early  1980s,  the  Army  instituted  a  new  series  of  MPT  and  human  factors 
improvement  projects.  These  projects  were  characterized  by  the  creation  of  a  new  control  apparatus, 
the  Army  MANPRINT  Office,  with  expectations  that  new  and  better  MPT  and  human  factors  tools 
would  be  developed.  The  Army's  HARDMAN  I  program  was  an  adaptation  of  a  Navy  MPT 
program  of  the  same  name.  This  latter  program  was,  in  essence,  an  adaptation  of  an  earlier  round 
of  MPT  tools  developed  by  AFHRL,  first  called  Coordinated  Human  Resources  Technology 
(CHRT),  later  called  Acquisition  of  Supportable  Systems  Evaluation  Technology  (ASSET).4 


4  The  basic  ideas  of  CHRT/ASSET  from  the  1970s  linger  on  in  the  form  of  comparability  analysis  and  R&M 
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CHRT/ASSET  consisted  of  a  family  of  systems  analysis  tools  organized  around  a  consolidated 
maintenance  task  data  base,  aimed  at  deriving  human  resources  requirements  for  new  systems. 
Human  resources  is  another  term  for  MPT.5 

HARDMAN  III  is  the  latest  effort  in  technically-oriented  MPT  tool  development  by  the 
Army  Research  Institute  for  the  Behavioral  and  Social  Sciences.  HARDMAN  III  documentation 
reviewed  on  this  ambitious  program  consisted  of  system  architecture  and  concept  exploration 
documents,  documentation  of  the  personnel  characteristics  requirements  prediction  subsystems,  and 
program  overview  briefings.  The  personnel  characteristics  prediction  concepts  have  been  the  initial 
focus  of  the  HARDMAN  III  development  effort,  as  these  represent  previously  underdeveloped 
capabilities. 

Like  many  MPT  projects,  HARDMAN  III  was  not  developed  as  an  extension  of  LSA,  or  of 
the  existing  WSAP  reporting  and  management  scheme.  This  independence  has  the  advantage  of 
producing  an  analysis  system  free  of  distortion;  introduced  by  trying  to  fulfill  the  requirements  of  a 
preexisting  reporting  scheme  like  LSA.  The  drawback  of  this  independence  is  the  subsequent 
requirement  to  interface  the  system  with  the  established  logistics  analysis  and  planning  structure. 
Work  is  currently  underway  to  develop  cross-references  between  the  partially  defined  HARDMAN 
process  and  data  universes  and  LSAR. 

HARDMAN  III  differs  from  SUMMA  in  that  it  is  a  set  of  stand-alone  programs  which 
combine  to  perform  a  more  complete  MPT  analysis.  In  addition,  the  human  factors  domain  is 
partially  integrated  into  the  HARDMAN  III  set  of  tools.  The  domain  of  the  HARDMAN  III  system 
exceeds  the  present  study’s  operational  definition  of  MPT  by  extending  itself  into  costing,  force 
management,  and  requirements  analysis,  as  well  as  human  factors.  The  description  of  the 
HARDMAN  III  presented  below  outlines  these  extensions. 


prediction  primarily.  LCOM  is  sometimes  associated  with  this  suite  of  tools  but  it  was  developed  separately. 
HARDMAN  III  is  not  to  be  confused  with  the  Navy  HARDMAN  program,  or  with  earlier  versions  of  Army 
HARDMAN  analytics,  or  with  CHRT/ASSET.  It  is  genuinely  new. 

5  In  the  1950s  and  1960s,  MPT  was  referred  to  as  the  "personnel  subsystem,"  again  using  the  systems  engineering 
model,  which  was  new  then.  The  more  things  change ... . 
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Module  Descriptions 


Figure  6  presents  the  most  recent  conceptualization  of  the  HARDMAN  III  system 
architecture.  The  individual  modules  are  discussed  below.  The  astute  reader  will  note  several 
potentially  beneficial  links  missing  from  the  HARDMAN  tools.  Immediately  apparent  examples  are 
lack  of  feedback  of  the  cost  analysis  module,  Army  Manpower  Cost  (AMCOST),  and  how  the  MPT 
tools  do  not  feedback  into  the  mission  requirements  analysis.  These  non  sequiturs  are  due  to  the 
HARDMAN  III  being  mainly  in  the  individual  requirements  development  and  prototyping  stage. 
Subsequent  elaboration  of  the  architecture  will  no  doubt  contain  a  closer  coupling  among  the 
separate  modules.  Consequently,  except  in  a  few  cases,  the  interrelations  among  modules  is  not 
emphasized  here. 


Figure  6.  HARDMAN  in  System  Architecture. 

System  Performance  and  RAM  Criteria  Estimation  Aid  (SPARC) 

The  M-CON,  P-CON,  and  T-CON  tools  all  develop  parameters,  constraints,  or 
relationships  for  injection  into  the  SE  process.  The  SPARC  (Dahl,  Laughery,  Archer,  &  O'Brien, 
1987)  tool  allows  the  automated  development  of  system  performance  requirements,  with  output 
similar  to  the  familiar  SORD  process.  This  tool  accesses  a  very  large  comparability  data  base  and 
provides  system  requirements  data  for  subsequent  task  analytic  and  comparability  activities  within 
the  HARDMAN  HI  analysis  framework. 
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The  input  flexibility  of  the  SPARC  system  includes  a  generic  ability  to  accept  Army  ground 
combat  models.  Inputs  and  requirements  from  this  source,  such  as  mobility  parameters  and  system 
attrition  rates,  differ  qualitatively  from  analogous  Air  Force  requirements  generated  from  mission 
effectiveness  studies.  In  the  latter,  performance  requirements  are  derived  in  the  forms  of  mission 
payload,  range,  and  other  parameters  of  interest  to  aeronautical  systems.  The  underlying  cause  of 
this  is  that,  in  the  Air  Force,  the  weapon  operator  function  can  often  be  analyzed  independently  of 
the  maintainer  and  other  logistic  support.  With  HARDMAN  III,  the  Anny  makes  no  such 
distinction.  The  operator  is  the  maintainer.  Also,  job  specialization  and  maintenance  centralization 
in  the  Army  are  less  pronounced  than  in  the  Air  Force,  making  eventual  manpower  calculations 
easier  in  many  respects.  This  results  in  considerable  deviation  from  the  MPT/SE  data  model  prior 
to  the  development  of  required  tasks  by  subsystem  and  R&M  data.  This  is  to  be  expected,  given 
the  differences  between  the  Army  and  the  Air  Force  requirements  analysis  process. 

Still,  comparability  analysis  is  fundamental  to  the  Army  MPT  requirements  development 
process.  The  practical  question  is  whether  the  Army  tools  provide  any  fresh  approaches  to  solving 
the  Air  Force  requirements  analysis  problem.  The  answer  appears  to  be  that  no  immediately 
applicable  analysis  approaches  significantly  different  from  the  Air  Force  processes  are  used  in  the 
HARDMAN  III  SPARC  requirements  analysis  process  (see  Table  4). 

M-C.QN. 

This  tool  is  designed  to  develop  manpower  constraints  from  characteristics  of  the 
predecessor  system  force.  Four  measures  are  developed:  (a)  maximum  allowable  crew  size,  (b) 
maximum  manhours,  (c)  operator  manpower,  and  (d)  total  maintenance  manpower.  The  M-CON 
tool  thus  fulfills  the  requirements  of  TDSTL  Process  Model  Task  1.3  called  Perform  Comparability 
Analysis.  Operator  manpower  is  added  to  the  analysis  and  changes  in  terminology  to  account  for 
Air  Force  and  Army  differences  are  needed. 

P-CON 

This  tool's  purpose  is  to  develop  estimates  of  personnel  quality  versus  performance 
characteristics  to  support  trade-offs  on  personnel  quality  issues.  This  is  a  comparability  analysis  in 
that  a  baseline  data  base  is  constructed  by  developing  a  quality  profile  assembled  from  the 
predecessor  system.  The  analogous  Air  Force  function  occurs  in  the  requirements  process  by 
proposing  and  coordinating  a  predecessor  system  that  provides  a  talent  pool  representative  of  that 
required  by  the  new  system,  an  event  that  gets  recorded  as  the  "Skill  Specialty  Code  Available  Man- 
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Table  4.  HARDMAN  III  SPARC  MPT  Analysis 


MPT  ACTIVITIES: 

1.0  Develop  functional  description. 

1.1  Identify  operational  requirements. 

INPUTS: 

None. 

OUTPUTS: 

Task  Demand  Rate  by  System 
Task  Allocation  to  Specialty 

1 .2  Propose/develop  comparable  system.  (Referred  to  as  a  "Baseline  system") 

INPUTS: 

Technology  type  by  subsystem 

Mission  Type  (Corresponding  to  "Sortie  Type"  in  data  model) 

OUTPUTS: 

Specialty/task  assignment  (combining  the  AFS/Subsystem  assignment  &  Tasks  by 
Subsystem  data  elements) 

Task  Times 
Crew  Sizes 


hours"  on  the  LSAR  All  card.  Any  increases  in  the  Air  Force  personnel  requirement  are  in  the 
development  of  new  AFSs,  an  activity  unavoidable  until  dealing  with  predicted  or  measured 
maintenance  requirements,  i.e.,  in  the  post-CDR  environment. 

A  personnel  capability  trade-off,  of  sorts,  can  occur  in  the  LSA  "Evaluation  of  Alternatives" 
analysis  for  the  Air  Force,  but  this  is  generally  couched  in  qualitative  terms,  as  underlying  data  are 
generally  lacking  for  technology  alternatives  not  yet  fielded.  The  Army  personnel  quality  situation, 
though,  is  much  different  from  the  Air  Force,  as  a  sizeable  proportion  of  the  Army  force  consists  of 
AS  VAB  Category  II  and  III  individuals.  The  HARDMAN  III  project  will  soon  produce  a  credible 
data  base  to  provide  quantitative  support  for  these  personnel  trade-offs.  Until  such  a  data  base 
appears,  the  P-CON  module  will  have  limited  applicability  to  the  Air  Force  MPT  analysis 
community.  At  the  moment,  P-CON  provides  no  analogy  for  the  MPT  Process  Model  proposed  for 
TDSTL. 
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T-CON 


This  tool  develops  training  trade-off  parameters  for  use  in  training  method  selection. 
Underlying  this  model  is  another  forthcoming  Army-specific  data  base.  The  Air  Force  equivalent 
function  is,  again,  associated  with  the  predecessor  system  training  requirements;  the  MPT/SE 
Process  task  is  1.3.2,  called  Compute  Comparable  Training  Requirements. 

The  current  definition  of  the  T-CON  tool's  function  would  preclude  its  use  within  the  SE 
process  of  the  Air  Force.  The  Air  Force  training  community  makes  the  decision  for  training 
materials  through  the  Instructional  System  Development  (ISD)  process.  It  is  not  clear  whether 
T-CON  would  fit  within  that  process. 

Manpower-Based  System  Evaluation  CMAN-SEVAU 

MAN-SEVAL  is  the  manpower  estimating  tool.  It  is  based  upon  a  microcomputer  hosted 
simulation,  Systems  Analysis  of  Integrated  Networks  of  Tasks  (SAINT).  The  calculations  entail 
developing  operator  mission  and  maintenance  time  lines,  and  simulating  a  combat  scenario  to 
determine  task  loading  and  manpower  requirements.  The  analysis  differs  from  the  Air  Force 
problem  by  coupling  operator  characteristics  with  the  maintenance  network.  The  manpower 
calculation  process  requires  detailed  task  information  of  about  the  same  level  as  LCOM,  and 
corresponds  to  the  MPT/SE  Compute  Manpower  tasks. 

Personnel-Based  System  Evaluation  (PER-SEVAU 

PER-SEVAL  is  a  task  simulation  approach  to  determine  the  required  quality  of  accessions  to 
enter  the  maintenance  career  field  associated  with  a  new  weapon  system.  The  data  requirements  for 
this  system  cotne  from  the  differential  personnel  quality  performance  data  base  that  feeds  the  P- 
CON  tool.  Outcomes  are  sets  of  Manpower  by  Military  Occupational  Specialty  (MOS)5  with  which 
system  design  trades  can  presumably  be  made. 

This  sort  of  integrated  operator/maintainer  time  line  analysis  is,  generally  speaking,  beyond 
the  state-of-the-art.  And  it  may  be  unnecessary  to  the  development  of  Air  Force  systems  in  any 
case.  Time  line  analysis  is  routinely  performed  for  Air  Force  crew  station  design  to  identify 
bottlenecks  in  the  user  interface  design  cycle  and  to  establish  performance  standards  for  proficiency 


5  MOS  is  the  Army  equivalent  to  the  Air  Force  AFS.  They  both  define  occupational  or  job  categories. 
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and  training.  Industrial  Engineering  task  decomposition  analysis  is  routinely  used  to  determine 
maintenance  performance  standards.  This  is  generally  focused,  in  the  development  of  Air  Force 
systems,  on  combat  turns  and  other  time  critical  activities.  The  activity  provides  no  real  MPT 
parameters  other  than  predicted  task  times.  No  activity  analogous  to  PER-SEVAL  has  been  included 
in  the  proposed  MPT/SE  Process  Model.  In  light  of  the  differences  we  observe  in  the 
operator/maintainer  role  definitions  between  the  two  Services,  it  is  difficult  to  envision  the 
immediate  application  of  the  PER-SEVAL  to  the  MPT/SE  process  proposed  here. 

Human  Operator  Simulator  fHOSN) 

HOS  (Version  V)  is  the  underlying  task  simulation  that  supports  the  PER-SEVAL  system. 
The  task  data  requirements  fall  somewhere  between  the  level  of  those  required  for  the  LSAR  C  and 
D  Records.  The  function  of  the  HOS  V  is  to  the  generic  Army  battle  scenario  what  LOOM  is  to 
base  operations  for  the  Air  Force.  If  HOS  V  were  well  integrated  with  the  LSAR  data  definitions, 
this  analysis  would  benefit  from  a  close  examination  of  HOS  V  as  well.  This  reanalysis  is  beyond 
the  scope  of  the  current  effort,  however. 

Army  Manpower  Cost  (AMCOST) 

AMCOST  is  the  cost  analysis  tool  being  developed  to  run  on  the  HARDMAN  III  data.  Cost 
modeling  is  not  included  in  the  MPT/SE  process  model  since  cost  modeling  .s  aiready  an  SE 
activity.  A  closer  integration  of  Air  Force  MPT  analysis  will  need  to  consider  cost  in  more  detail 
since  cost  is  the  most  relevant  metric  with  which  to  perform  more  training  versus  more  manpower 
trade-offs.  Discussion  of  this  topic  can  be  found  in  Miller  (1988)  and  Boyle  (1989). 

FORCE 

This  is  a  proposed  Army-wide  management  and  planning  tool.  This  class  of  analysis  is 
considered  outside  the  scope  of  MPT/SE  analysis  as  defined  for  this  study  inasmuch  as  it  deals  with 
trade-offs  among  multiple  weapon  systems.  The  MPT/SE  activity  concerned  with  force-wide 
constraints  is  Task  1.3.3  Compute  Comparable  Accessions  Requirement.  Here,  the  impacts  of  the 
new  system's  overall  manpower  requirements  are  ascertained  and  submitted  to  USAF  Headquarters 
for  force  planning  and  management.  The  advantage  of  integrating  this  function  with  a  system 
designed  for  use  during  system  acquisition  is  clear,  but  the  data  integration  problem,  restricted 
accession  numbers  and  quality  required,  take  it  somewhat  outside  the  scope  of  Air  Force  acquisition 
processes. 
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Manpower  Capabilities  (MAN-CAP’)  and  SORD 


MAN-CAP  is  a  unit-level  manpower  simulation  patterned  after  the  Air  Force's  LCOM 
model.  The  Air  Force  equivalent  to  the  SORD  is  some  form  of  the  now-abandoned  Integrated 
Manpower  Personnel  and  Consolidated  Training  System  (IMPACTS)  summary.  The  analysis 
activities  capable  of  supporting  these  reports  are  the  subject  of  the  MPT/SE  Process  Model. 

Soldier  Characteristics  Availability  Data  Method  (SCAD^  and  Integrated  Characteristics  and 
Availability  Redesign  Utility  System  (ICARUS) 

SCAD  is  an  auxiliary  program  to  the  force  management  program  that  attempts  to  diagnose 
and  prescribe  steps  to  redress  shortfalls  in  the  Army's  total  manning  profile.  ICARUS  is  a  proposed 
specialty  management  tool  that  supports  the  SE  system  redesign/respecification  activity.  Within  the 
MPT/SE  Process  Model  the  analogous  function  is  the  requirements  determination  function,  boiling 
down  to  Manpower  by  AFS  constraints.  The  ICARUS  function  is  handled  by  the  5.0  Reconsider 
System  Specification  task  associated  with  routine  analysis  of  field  performance  data  and  the 
evolving  threat.  As  the  SCAD  and  ICARUS  modules  are  not  yet  in  development  or  possess  firm 
functional  requirements,  it  is  likely  that  these  modules  will  be  redefined  in  future  versions  of  the 
HARDMAN  III  architecture. 


Evaluation 

Hie  HARDMAN  III  architecture  covers  the  MPT  domain  with  three  exceptions.  The  first  is 
not  explicitly  making  the  comparability/allocated/predicted/measured  distinction.  This  shortfall 
reflects  the  requirement  analysis  for  the  system  not  making  the  distinction  among  these  classes  of 
data.  In  all  likelihood,  the  only  impact  will  be  in  not  considering  alternatives  to  the  HOS  V 
simulation  in  manpower  analysis.  The  only  shortfall  of  this  would  be  in  an  eventual  development  of 
the  analysis  system  along  mathematical  programming  lines,  where  the  computational  and  control 
specification  complexity  of  a  simulation  language  will  limit  the  system  design  options. 

The  second  shortfall  is  in  not  computing  the  accession  requirement.  This  too  could  impact 
future  development  of  the  system.  This  sort  of  analysis  is  necessary  in  computing  a  complete  cost 
for  a  fielded  force,  including  training,  rank,  and  time-in-grade  requirements. 
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The  third  shortfall,  from  an  Air  Force  perspective,  is  in  not  explicitly  considering  the  task- 
to-AFS  allocation  problem.  Specifically,  HARDMAN  III  does  not  readily  handle  AFS  definition 
options.  Although  it  might  be  altered  in  some  way  to  handle  SUMMA  types  of  analysis, 
HARDMAN  III  was  not  intended  to  look  at  an  altered  MPT  environment.  Hence,  a  full-up 
HARDMAN  III  analysis  on  an  Air  Force  system  would  beg  the  questions  of  most  interest  to  Air 
Force  MPT  people:  How  many  AFSs  should  there  be,  and  what  does  it  take  to  create  them? 

None  of  these  shortfalls  is  fatal.  The  HARDMAN  III  system  architecture  i  solving  and  it 
appears  that  it  could  accommodate  any  of  these  concerns  in  future  versions.  Problematical  is  the 
HARDMAN  concern  with  the  personnel  quality  issue.  The  Army  claims,  on  the  one  hand,  that  it 
has  data  to  support  this  design  analysis  strategy,  and,  on  the  other,  that  it  is  developing  a  task 
analysis  strategy  based  upon  a  human  factors  model  linking  user  response  time  to  system  interface 
complexity  (Fitts'  law).  Whichever  is  the  case,  an  empirical  demonstration  of  one  or  the  other  of 
these  approaches  is  needed  before  a  prescriptive  approach  such  as  this  warrants  fielding. 

Precisely  targeting  aircraft  system  development  to  a  certain  intellectual  capacity  of  the 
maintainer  force  is  simply  beyond  the  state  of  the  art.  Human  factors  recommendations  in  aircraft 
maintenance  tend  toward  recommendations  of  known  workable  design  solutions  or  prototype 
evaluations  to  select  the  "best"  option  from  a  predesigned  range.  With  increasing  periods  of 
technical  development  occurring  between  new  system  development,  these  solutions  will  become 
increasingly  less  attractive.  Moderating  the  user  interface  complexity  on  very  complex  systems  are 
the  issues  of  R&M  and  testability.  A  closer  coupling  of  the  HARDMAN  III  notions  with  these 
logistics  considerations  is  desirable  in  achieving  an  analytic  solution  to  the  complexity  issue. 

VII.  CONCLUSIONS 

The  MPT/SE  Process  Model  of  this  study  seems  to  provide  a  useful  framework  for 
describing  and  comparing  MPT  analysis  activities.  This  framework,  and  its  associated  Data  Model, 
suitably  coordinated,  will  serve  as  a  framework  for  future  AFHRL  work  in  MPT  and  logistics 
analysis.  Specifically,  the  TDSTL  follow-on  effort  will  examine  the  R&M  and  manpower  data 
sources  and  calculation  techniques  to  determine  the  accuracy  with  which  these  parameters  can  be 
specified.  We  will  also  determine  suitable  analysis  alternatives  for  eich  application  chosen.  Of 
particular  concern  is  the  manpower  calculation. 

The  MPT  MOMs  identified  by  this  effort  shall  be  further  developed,  with  case  histories 
serving  as  testbeds  to  demonstrate  the  feasibility  and  desirability  of  these  parameters  in  MPT 
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analysis.  This  effort  will  serve  as  the  front  end  to  the  development  of  prototype  analytic  tools  for 
use  in  the  short-  and  medium-term  environment.  Two  other  analysis  efforts  applicable  to  TDSTL 
development  are  discussed  below. 


Integrated  MPT  Analysis  and  Computer-Aided  Design  UMACADI 

The  IMACAD  effort  is  developing  a  manpower  analysis  tool  applicable  to  the  Develop 
Functional  Description  phase  of  the  MPT/SE  process  model.  IMACAD  will  do  for  comparability 
what  SUMMA  has  done  for  AFS  determination,  namely,  develop  analytic  flexibility  within  the 
information  environment  with  which  we  must  deal.  The  trade-off  between  R&M  parameters,  on  the 
one  hand,  and  Manpower  by  AFS,  on  the  other,  is  incompletely  exploited  in  the  present 
environment.  The  R&M  community  tends  toward  maintenance  manhours  rather  than  the  more 
germane  Manpower  by  AFS  as  the  MOM. 

The  IMACAD  product  will  be  a  manpower  comparability  analysis  workstation  with  links  to 
future  personnel  and  training  analysis  facilities.  Part  of  the  TDSTL  follow-on  will  incorporate  the 
IMACAD  framework  to  develop  and  compare  manpower  analysis  alternatives.  The  goal  of  the 
effort  is  to  provide  a  maximally  sophisticated  analysis  facility  while  holding  the  analyst  interface 
complexity  to  a  level  equal  to  or  below  that  currently  in  use  within  the  R&M  community,  i.e.,  that 
of  a  reliability  allocation  spreadsheet  model. 

Design  Evaluation  for  Personnel.  Training,  and  Human  Factors  (DEPTH ~) 

Culminating  this  Air  Force  research  is  a  planned  AFHRL/LRL  effort  to  integrate  the 
SUMMA,  IMACAD,  and  human  factors  technologies  into  a  unified  workstation  environment.  The 
MPT  Process  and  Data  Models  developed  under  TDSTL  and  IMACAD  are  intended  to  benefit  this 
undertaking  by  defining  the  logistic  planning  interface  to  the  design  interface  areas  of  human  factors 
and  reliability  engineering.  The  other  major  AFHRL  projects  providing  technology  for  this  effort 
are  the  Crew  Chief,  R&M  in  Computer-Aided  Design  (RAMCAD),  and  SUMMA. 

Technology  Requirements 

Beyond  the  previously  mentioned  R&M  to  manpower  disconnect,  other  disconnects  within 
the  MPT  environment  can  be  pointed  out.  The  most  obvious  one  is  the  perennial  lack  of 
documentation  among  equipment  design  characteristics,  job  design,  and  training  and  personnel 
requirements.  Previous  attempts  to  solve  this  problem,  ranging  from  attempts  to  measure  equipment 
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and  job  complexity  to  huma>.  reliability  measurement,  have  met  with  little  lasting  success.  The 
Army  HARDMAN  effort,  and  several  pre-DEPTH  efforts  are  attempting  to  address  this  problem 
from  one  direction  or  another.  The  Crew  Chief  program  attempts  to  (partially)  solve  the  problem 
analytically  by  physically  modeling  the  environment  and  deriving  anthropometric  measurements  of 
the  various  maintenance  tasks.  The  Comparative  Anatomy  of  Maintenance  Tasks  (CAMT)  research 
is  reviewing  competing  formats  of  comparability  task  data  with  the  aim  of  finding  the  one  most 
conducive  to  accurate  comparability  analysis.  These  efforts  underscore  basic  gaps  in  our  knowledge 
of  human  performance. 

The  Unknown  Relationships  Problem 

The  problem  of  unknown  MPT  relationships  eventually  arises  in  all  thoughtful  MPT  efforts. 
Task  and  hardware  correlates  of  maintenance  technician  skill  level  requirements,  particularly,  are 
mentioned  as  a  statistic  that  would  let  us  streamline  Air  Force  maintenance  by  reducing  task  time, 
training,  false  removal  rates,  and  other  maintenance  costs.  Sensitivity  analyses  (such  as  reported  in 
Garcia  &  Racher,  1981)  show  significant  manpower  deltas  due  to  estimated  task  time  differences 
between  unskilled  and  journeyman-level  aircraft  maintainers.  Unfortunately,  we  know  little  that 
could  prove  prescriptive  about  this  particular  relationship. 

Figure  7  presents  graphically  other  relationships,  about  which  we  know  little,  that  could  be 
of  use  prescriptively.  The  open  squares  are  areas  about  which  we  know  nothing  of  much 
prescriptive  value.  The  squares  marked  1  are  the  main  concern  of  the  science  of  human  factors. 
Squares  marked  2  are  the  science  of  testability.  Squares  marked  3  are  what  training  research  deals 
with.  No  information  exists  correlating  maintainers’  performance  criteria  with  the  Air  Force 
classification  system.  Performance  criteria  are  in  general  not  collected.  Personnel  performance 
information  in  the  system  development  process  comes  solely  from  comparable  and  predecessor 
systems'  maintenance  technician  population. 

Substantial  progress  in  MPT  planning  will  come  with  the  integration  of  knowledge  about  the 
relationships  listed  in  Figure  7  with  the  R&M-based  MPT  analysis  that  is  the  current  state  of  the  art. 
It  would  be  gratifying  to  see  sponsorship  available  for  investigation  of  these  potentially  valuable 
relationships. 

The  Air  Force's  ability  to  exploit  a  closer  personnel  management  of  the  skill  level/task  time 
relationship  in  the  real  world  is  questionable.  We  can  expect,  at  most,  an  improvement  of  scarcely  6 
percent  in  average  task  time  and  a  concomitant  manpower  reduction  of  one  maintenance  technician 
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Task  Training 

Training  Native  Unnecessary  Performance  Equipment  Success 

Time  Ability  Removals  Time  Attributes  Portability 


Training  Time  .  3 

Native  Ability  - 

Unneccesary 

Removals  .  2  — 

Task  Performance 

Times  -  1  — 

Equipment 

Attributes  2  1  - 

Training  Success 

Probability  3  -  -  — 


Figure  7.  Unknown  Relationships  Matrix. 

in  20  assuming  a  maintenance  task  time  standard  deviation  to  mean  ratio  of  .29  (the  standard  value 
used  within  the  LCOM  community)  and  a  correlation  between  task  time  and  a  predictor  of  .30  (a 
typical  finding  in  selection  research).  This  prediction  is  made  assuming  only  the  top  50  percent  of 
individuals  on  the  predictor  are  assigned  to  maintenance  jobs. 

Equipment  Design  Characteristics 

The  MPT/SE  Process  Model  points  up  the  close  association  between  MPT  and  R&M 
analysis.  If  this  is  a  fruitful  direction  for  integration,  then  the  incorporation  of  failure  mode  analysis 
and  testability  considerations  into  measures  of  system  complexity  is  the  logical  next  step  in 
improving  the  user  interface  with  equipment  design.  LSAR  data  already  include  information  on  how 
a  fault  is  to  be  detected  on  the  B1  record.  Potentially  important  variables  in  this  domain  include  the 
variables  Failure  Mode  Indicator,  Ambiguity  Group,  Fault  Isolation  Time,  and  Means  of  Detection. 
The  initial  goal  of  investigating  this  information  would  be  to  determine  how  much  additional 
training  is  required  to  handle  multiple  failure  mode  indicators  and  means  of  detection.  The  design 
implications  of  this  information  would  be  the  emergence  of  a  trade-off  among  degree  of  automated 
fault  isolation,  test  equipment,  and  training  requirements. 
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Further  Developments 


Several  further  developments  of  TDSTL  are  planned.  The  first  effort  is  IMACAD,  being 
performed  concurrently  with  TDSTL.  A  direct  follow-on  to  TDSTL  (TDSTL  II)  is  also  planned. 
The  culmination  of  these  and  related  efforts  is  in  the  DEPTH  project. 

IMACAD 

The  IMACAD  project  is  a  development  and  demonstration  of  a  next  generation  design 
interface  that  more  closely  integrates  the  SE  equipment  design  strategy,  R&M,  and  MPT  issues. 
The  approach  pursued  is  to  develop  manpower  analysis  as  an  extension  of  the  current  R&M 
allocation  and  monitoring  process.  The  automated  tool  developed  is  a  workstation  for  the 
supportability  engineer  that  ties  logistic  considerations  to  "hard"  engineering  design  parameters, 
such  as  reliability,  weight,  size,  power  consumption,  and  packaging,  which  are  the  issues  that  the 
supportability  engineer  discusses  with  the  design  engineers. 

The  improvement  the  IMACAD  workstation  provides  is  in  providing  the  logistic 
implications  of  the  engineering  design  parameters  in  a  timely  fashion,  empowering  the  design  team 
to  examine  alternatives  during  the  design  activity  itself,  rather  than  dealing  with  preordained 
reliability  design  goals,  developed  without  reference  to  the  actual  detail  design  opportunities  or 
limitations.  Opportunities  for  tangible  logistics  economies  through  manpower  savings,  or  changes 
in  support  equipment  or  level  of  repair  requirements,  will  be  identified  by  the  supportability 
engineer,  who  will  query  the  design  team  as  to  the  feasibility  of  changes  to  the  primary  engineering 
parameters  to  enable  the  logistic  possibility  identified  by  the  IMACAD  process.  Likewise,  the 
impact  of  design  implementation  shortfalls,  and  the  range  of  plausible  compensatory  actions,  could 
be  assessed  during  the  design  pneess,  resulting  in  less  overall  redesign  and  system  development 
delay. 


The  implementation  of  the  IMACAD  system  as  a  supportability  engineering  function  rather 
than  at  the  bench-level  design  station  is  due  to  the  system-wide  nature  of  logistic  issues  and  the 
requirement  that  the  design  engineer  only  deal  with  issues  over  which  he  has  control.  The  final 
report  suggests  methods  for  integrating  IMACAD  with  training,  personnel,  and  engineering 
analyses. 
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TDSTL  II 


The  follow-on  TDSTL  effort  expands  the  IMACAD  software  toward  use  as  an  LSA-based 
trade-study  alternative  to  R&M,  simulation  manpower  modeling,  and  cost  analysis  by  integrating 
and  demonstrating  these  additional  functions  in  the  system.  The  major  effort  will  be  an  evaluation 
and  validation  of  available  analytic  manpower  estimation  techniques.  Ties  to  diverse  levels  of  repair 
analysis,  including  depot  workload,  training  resource  prediction,  and  personnel  issues,  will  be 
developed  and  demonstrated  in  the  development  of  cost  analysis  features  to  the  system.  An 
extensive  demonstration  of  the  system  is  tentatively  planned,  either  as  a  separate  effort  or  as  part  of 
the  DEPITI  effort. 

DEPTH 


Whereas  TDSTL  and  IMACAD  explored  the  MPT  issues  amenable  to  improved  control 
through  a  revision  of  the  R&M  design  interface,  the  DEPTH  project  seeks  to  improve  the  tics 
between  human  factors  analysis,  MPT,  and  logistic  analysis.  The  most  promising  approach  is 
through  computer  man-modeling,  which  replaces  detailed  manual  task  analysis  and  human  factors 
prototyping  with  a  detailed  analysis  of  a  three-dimensional  model  of  the  emerging  design.  Analytic 
ties  between  R&M  analysis  and  the  man-model  then  occur  through  task  time  estimations  from  the 
man-modeling  system.  The  anthropometric  and  ergonomic  personnel  characteristics,  safety,  and 
related  workplace  information  are  also  developed  by  the  man-modeling  system. 

The  conventional  human  factors  task  analysis  is  avoided,  being  replaced  by  an  automated 
task  identification/task  analysis  generation  process.  This  process  avoids  detailed  task  analysis 
altogether  and  generates  the  other  task  analysis  products:  training  materials  and  TOs,  directly  from 
the  man-modeling  facility. 

Additional  analyses  that  may  be  profitably  integrated  into  an  integrated  (and,  incidentally, 
revised)  human  subsystem  analysis  include  repair-level  analysis  and  testability  analysis,  as  trades 
between  these  two  issues,  and  R&M  and  MPT  issues  exist  but  are  only  performed  as  a  function  of 
meeting  minimum  turn  times,  very  early  in  the  design  cycle. 
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LIST  OF  ACRONYMS 


Aa 

Achieved  Availability 

Ai 

Inherent  Availability 

Ao 

Operational  Availability 

AFHRL 

Air  Force  Human  Resources  Laboratory 

AFHRL/LRA 

Air  Force  Human  Resources  Laboratory/Acquisition  Logistics  Branch 

AFHRL/LRL 

Air  Force  Human  Resources  Laboratory/Logistics  Systems  Branch 

AFLC 

Air  Force  Logistics  Command 

AFS 

Air  Force  Specialty 

AFWAL/FG 

Air  Force  Wright  Aeronautical  Laboratory/Flight  Dynamics 

AGE 

Aerospace  Ground  Equipment 

AMCOS 

Army  Manpower  Cost 

AOR 

Annual  Operating  Requirements 

ATI’ 

Advanced  Theater  Transport 

AVAIL  MAN-HOURS 

Skill  Specialty  Code  Available  Man-Hours 

BOC 

Best  Operational  Capability 

CAMT 

Comparative  Anatomy  of  Maintenance  Tasks 

CDR 

Critical  Design  Review 

DOD 

Department  of  Defense 

FSN 

Federal  State  Number 

HFE 

Human  Factors  Engineering 

HOSV 

Human  Operator  Simulator  (Version  V) 

ICAM 

Integrated  Computer-Aided  Manufacturing  Definition 

ICARUS 

Integrated  Characteristics  and  Availability  Redesign  Utility  System 

EDEF 

Integrated  Computer-Aided  Manufacturing 

IMACAD 

Integrating  Manpower  Analysis  with  Computer-Aided  Design 

IMPACTS 

Integrated  Manpower  Personnel  and  Consolidated  Training  System 

ISD 

Instructional  System  Development 

LCOM 

Logistics  Composite  Model 

LRU 

Line  Replaceable  Unit 

LSA 

Logistics  Support  Analysis 

LSAR 

Logistics  Support  Analysis  Record 

MAJCOM 

Major  Air  Command 

MAMBT 

Mean  Active  Maintenance  Downtime 
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LIST  OF  ACRONYMS  (Cont.) 


MAN-CAP 

Manpower  Capabilities 

MANPRINT 

Manpower  and  Personnel  Integration 

MAN-SEVAL 

Manpower-Based  System  Evaluation 

MAX  TTR 

Maximum  Time  To  Repair 

MIL-STD 

Military  Standard 

MOMs 

Measures  of  Merit 

MOS 

Military  Occupational  Specialty 

MPT 

Manpower,  Personnel,  and  Training 

MTBF 

Mean  Time  Between  Failure 

MTBM  INDUCED 

Mean  Time  Between  Maintenance,  Induced 

MTBM  INHERENT 

Mean  Time  Between  Maintenance,  Inherent 

MTBM  NO  DEFECT 

Mean  Time  Between  Maintenance,  No  Defect 

MTBPM 

Mean  Time  Between  Preventative  Maintenance 

MTBMA 

Mean  Time  Between  Maintenance  Actions 

MTTR 

Mean  Time  To  Repair 

NO  SSC 

Number  of  Persons  Per  Skill  Specialty  Code 

O/MLVL 

Operations/Maintenance  Level 

PAA 

Primary  Assigned  Aircraft 

PDP 

Procurement  Decision  Package 

PDR 

Preliminary  Design  Review 

PER-SEVAL 

Personnel-Based  System  Evaluation 

PERS  ID 

Person  Identifier 

PME 

Precision  Measurement  Equipment 

QPA 

Quantity  Per  Aircraft 

QTY  SSC  AVAIL 

-Quantity  Skill  Speciality  Code  Available 

R&D 

Research  &  Development 

R&M 

Reliability  &  Maintainability 

RAMCAD 

Reliability  &  Maintainability  in  Computer-Aided  Design 

S3 

Specialty  Structuring  System 

SAINT 

Systems  Analysis  of  Integrated  Networks  of  Tasks 

SCAD 

Soldier  Characteristics  Availability  Data  Method 

SE 

Systems  Engineering 

SEI 

Systems  Exploration,  Inc. 
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LIST  OF  ACRONYMS  (Com.) 


SE  REQUIRED 

Support  Equipment  Required 

SLC 

Skill  Level  Code 

SOFA 

Special  Operations  Forces  Aircraft 

SON 

Statement  of  Need 

SORD 

Statement  of  Operational  Requirements 

SOW 

Statement  of  Work 

SPARC 

System  Performance  and  RAM  Criteria  Estimation  Aid 

SPO 

System  Program  Office 

SRU 

Shop  Replaceable  Unit 

SSC 

Skill  Specialty  Code 

SSEVAL 

Skill  Specialty  Evaluation  Code 

SUMMA 

Small  Unit  Maintenance  Manpower  Analyses 

TDSTL 

Top-Down  System  Tool  for  Logistics 

TRN  EQP 

Training  Equipment  Requirements  Code 

WSAP 

Weapon  System  Acquisition  Process 

WUC 

Work  Unit  Code 

APPENDIX  A:  FINAL  MPT/SE  PROCESS  MODEL 
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FINAL  MPT/SE  PROCESS  MODEL 


TQP.-Lcy.el, s  try  QUirg 


1 .0  Develop  functional  description. 

2.0  Assign  functional  allocation. 

3.0  Design  and  integrate  subsystems. 

4.0  Evaluate  system  performance. 

5.0  Reconsider  system  specification. 

Table  1  lists  the  task  breakout  under  each  SE  task. 

Level  MPT  Task  Descriptions 

1.0  Develop  functional  description.  This  analyst  assembles  information  about  the  emerging 
weapon  system  viable  concepts  for  use  in  subsequent  analyses.  The  major  activity  within  this 
activity  is  the  determination  of  the  maintenance  task  demands. 

1.1  Identify  operational  requirements.  The  analyst  assembles  information  about  the 
system's  mission.  The  main  purpose  behind  this  is  to  aid  future  translation  of  R&M  parameters 
from  operational  time  metrics  to  24-hours  per  day,  available  maintenance  time. 

1.2  Propose/develop  comparable  system.  The  comparability  system  is  a  combination  of 
subsystems  of  similar  technology  used  on  aircraft  of  similar  configuration  and  mission  as  the 
emerging  system.  The  analyst  must  develop  and  coordinate  a  straw  man  R&M  profile  and 
maintenance  concept,  incorporating  subject  matter  experts  and  the  variety  of  existing  field 
experience  to  determine  reasonable  expectations  for  emerging  system  R&M  performance. 

1.3  Perform  comparability  analysis.  The  analyst  predicts  the  logistic  behavior  of  the 
emerging  system  through  the  comparability  system.  Typically,  the  logistic  requirements  to  sustain 
a  given  sortie  rate  are  computed  with  limited  trade-off  results  also  often  being  developed. 

1.3.1  Compute  comparable  manpower.  Three  algorithms  are  identified:  (a)  the  R&M 
approach  sums  the  maintenance  requirements  across  systems  and  multiplies  this  by  utilization  to 
obtain  manpower;  (b)  queuing  theory  employs  analytic  probability  modeling  to  derive  manpower 
numbers;  and  (c)  simulation  models  compute  logistic  resources  numerically. 

1.3.2  Compute  comparable  training  requirements.  A  manpower  by  AFS  statistic 
allows  an  estimate  of  the  total  and  sustaining  training  burden  entailed  by  the  system  to  be 
estimated. 


A-2 


1.3.3  Compute. -Comparable  accessions  requirements.  The  manpower  by  AFS 
statistics  and  the  ongoing  training  requirement  allow  the  computation  of  total  personnel  in  the 
system  required  to  sustain  the  requisite  end  strength. 

2.0  Assign  functional  allocation.  The  analyst  must  collect  R&M  data  from  the  reliability  and 
human  factors  engineer  to  support  an  evaluation  of  the  system  performance  using  allocated,  as 
opposed  to  comparability,  system  metrics. 

2. 1  Update  operational  requirements.  The  sortie  type  and  rate  need  to  be  checked  in  case  of 
change  of  system  mission,  number  of  systems,  threat,  and  so  on. 

2.2  Allocate  MPT  MOMS  to  subsystems.  R&M  and  AFS  to  task  assignments  are  Finalized. 
These  need  to  be  noted  for  subsequent  analysis.  Trade-off  analysis  would  be  very  helpful  in  this 
process.  This  is  the  purpose  of  the  IMACAD  effort. 

2.3  Estimate  MPT  MOMs  from  functionally  allocated  baseline  system.  This  paragraph 
repeats  the  activities  of  paragraph  1.3,  using  allocated  data. 

2.3.1  Compute  allocated  manpower. 

2.3.2  Compute  allocated  training  requirements. 

2.3.3  Compute  allocated  ascessions  requirement. 

3.0  Design  and  integrate  subsystems.  The  emergence  of  a  hard  design  of  an  emerging  system 
allows  more  accurate  predictions  of  system  performance  to  be  developed  within  the  engineering 
activity.  The  R&M  prediction  process  is  augmented  by  prototyping  and  laboratory  study  in  critical 
areas.  The  logistic  impact  of  deviations  from  allocated  design  parameters  is  the  major  concern  to 
the  analyst.  Anecdotal  sources  lead  one  to  believe  that  this  information  is  not  available  in  a  timely 
fashion. 

3 . 1  Update  operational  requirements.  The  sortie  type  and  rate  need  to  be  checked  in  case  of 
change  of  system  mission,  number  of  systems,  threat,  and  so  on. 

3.2  Estimate  MPT  MOMs  from  subsystem  design.  This  paragraph  repeats  the  activities  of 
paragraph  1.3,  using  allocated  data. 

3.2.1  Compute  predicted  manpower. 

3.2.2  Compute  predicted  training  requirements. 

3.2.3  Compute  predicted  accessions  requirement. 

4.0  Evaluate  system  performance.  The  MPT  domain  becomes  the  manpower  domain.  Differing 
operating  and  maintenance  concepts  that  evolve  as  a  system  are  employed  by  various  commands, 
and  in  various  environments  justify  separate  manpower  analyses  for  diverse  operations. 

4. 1  Update  operational  requirements.  The  sortie  type  and  rate  need  to  be  checked  in  case  of 
change  of  system  mission,  number  of  systems,  threat,  and  so  on. 

4.2  Estimate  MPT  MOMs  from  Field  experience  data.  This  paragraph  repeats  the  activities 
of  paragraph  1.3,  using  allocated  data. 
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4.2.1  Compute  predicted  manpower. 

4.2.2  Compute  predicted  training  requirements.  This  activity  becomes 
institutionalized  in  the  training  command. 

4.2.3  Compute  predicted  acessions  requirement.  This  activity  becomes 
institutionalized  in  the  personnel  community. 

5.0  Reconsider  system  specification.  The  impact  of  proposed  configuration  changes  to  a  weapon 
system  needs  to  be  evaluated,  although  generally  speaking,  most  modification  programs  certify 
themselves  out  of  any  logistic  analysis  requirements.  Of  more  interest  are  the  periodic  studies 
looking  at  altemadve  support  concepts  such  as  a  revised  level  of  repair  or  APS  assignments. 

5.1  Update  operation  parameters.  The  sortie  type  and  rate  need  to  be  checked  in  case  of 
change  of  system  mission,  number  of  systems,  threat,  and  so  on. 

5.2  Propose  and  evaluate  revised  system  support  concepts.  The  current  support  concepts 
support  engineering  activity  centers  on  reliability  improvement  or  acquiring  additional  spares  As 
logistic  elements  often  can  compensate  for  each  other,  the  potential  improvement  from  MPT 
changes  may  need  to  be  estimated  in  this  context. 

5.3  Evaluate  candidate  system  upgrades.  This  activity  is,  essentially,  a  comparability 
analysis,  using  the  existing  weapon  system  as  its  own  comparable  system. 
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FINAL  MPT  DATA  MODEL  BY  TASK 


1 .0  Develop  functional  description. 

1 . 1  Identify  operadonal  requirements. 

INPUTS:  None 

OUTPUTS :  Number  of  PA  A 

Sortie  Type 
Sortie  Rate  by  Type 
Sortie  Duration  by  Type 

1 .2  Propose/develop  comparable  system. 

INPUTS:  Technology  Type  by  Subsystem 

Sortie  Type 

OUTPUTS:  AFS/Subsystem  Assignment 

Reliability  by  Subsystem  (Comparable  Reliability) 
Maintenance  Tasks  by  Subsystem 
Maintenance  Task  Times 

1 .3  Perform  comparability  analysis. 

1.3.1  Compute  comparable,  manpower. 

INPUTS:  AFS/Subsystem  Assignment 

Reliability  by  Subsystem  (Comparable  Reliability) 
Support  Equipment 
Maintenance  Tasks  by  Subsystem 
Maintenance  Task  Times 
Maintenance  Crew  Size  by  Task 
OUTPUTS :  Comparability  Required  Manpower  by  AFS 

1.3.2  Compute  comparable  training  requirements. 

INPUTS :  Comparability  Required  Manpower  by  AFS 

Training  Requirements  by  AFS 
OUTPUTS :  Comparability  System  Training  Requirements 

1.3.3  Compute  comparable  accessions  requirement. 

INPUTS :  Comparability  Required  Manpower  by  AFS 

Comparability  System  Training  Requirements 
Historic  Personnel  Turnover  Rate  by  AFS 
OUTPUTS:  Comparability  Required  Accessions  by  AFS  per  year 
2.0  Assign  functional  allocation. 

2.1  Update  operational  requirements. 
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INPUTS:  None 

OUTPUTS :  Number  of  PAA 
Sortie  Type 
Sortie  Rate  by  Type 
Sortie  Duration  by  Type 

2.2  Allocate  MPT  MOMs  to  subsystems. 

INPUTS:  Maintenance  Tasks  by  Subsystem 

OUTPUTS:  Reliability  by  Subsystem  (Allocated  Reliability) 

Maintenance  Task  Times 
Allocated  System  Reliability 
Allocated  System  Maintainability 

2.3  Estimate  MPT  MOMs  from  functionally  allocated  baseline  system. 

2.3.1  Compute  allocated  manpower. 

INPUTS:  AFS/Subsystem  Assignment 

Reliability  by  Subsystem  (Allocated  Reliability) 
Support  Equipment 
Maintenance  Tasks  by  Subsystem 
Maintenance  Task  Times 
Maintenance  Crew  Size  by  Task 
OUTPUTS:  Allocated  Required  Manpower  by  AFS 

2.3.2  Compute  allocated  training  requirements. 

INPUTS:  Allocated  Required  Manpower  by  AFS 

Training  Requirements  by  AFS 
OUTPUTS :  Allocated  System  Training  Requirements 

2.3.3  Compute  allocated  accessions  requirement. 

INPUTS :  Allocated  Required  Manpower  by  AFS 

Allocated  System  Training  Requirements 
Historic  Personnel  Turnover  Rate  by  AFS 
OUTPUTS:  Allocated  Required  Accessions  by  AFS  per  year 
3.0  Design  and  integrate  subsystems. 

3 . 1  Update  operational  requirements. 

INPUTS:  None 

OUTPUTS:  Number  of  PAA 
Sortie  Type 
Sortie  Rate  by  Type 
Sortie  Duration  by  Type 
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3.2  Estimate  MPT  MOMs  from  subsystem  design. 

3.2. 1  Compute  predicted  manpower. 

INPUTS:  AFS/Subsystem  Assignment 

Reliability  by  Subsystem  (Predicted  Reliability) 
Support  Equipment 
Maintenance  Tasks  by  Subsystem 
Maintenance  Task  Times 
Maintenance  Crew  Size  by  Task 
OUTPUTS :  Predicted  Required  Manpower  by  AFS 

3.2.2  Compute  predicted  training  requirements. 

INPUTS:  Predicted  Required  Manpower  by  AFS 

Training  Requirements  by  AFS 
OUTPUTS :  Predicted  System  Training  Requirements 

3.2.3  Compute  predicted  accessions  requirement. 

INPUTS:  Predicted  Required  Manpower  by  AFS 

Predicted  System  Training  Requirements 
Historic  Personnel  Turnover  Rate  by  AFS 
OUTPUTS :  Predicted  Required  Accessions  by  AFS  per  year 
4 . 0  Evaluate  system  performance. 

4.1  Update  operational  requirements. 

INPUTS:  None 

OUTPUTS:  Number  of  PAA 

Sortie  Type 
Sortie  Rate  by  Type 
Sortie  Duration  by  Type 

4.2  Estimate  MPT  MOMs  from  field  experience  data. 

4.2. 1  Compute  predicted  manpower. 

INPUTS:  AFS/Subsystem  Assignment 

Reliability  by  Subsystem  (Measured  Reliability) 
Support  Equipment 
Maintenance  Tasks  by  Subsystem 
Maintenance  Task  Times 
Maintenance  Crew  Size  by  Task 
OUTPUTS :  Predicted  Required  Manpower  by  AFS 

4.2.2  Compute  predicted  training  requirements. 

INPUTS:  Predicted  Required  Manpower  by  AFS 
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Training  Requirements  by  AFS 
OUTPUTS:  Predicted  System  Training  Requirements 

4.2.3  Compute  predicted  accessions  requirement. 

INPUTS:  Predicted  Required  Manpower  by  AFS 

Predicted  System  Training  Requirements 
Historic  Personnel  Turnover  Rate  by  AFS 
OUTPUTS:  Predicted  Required  Accessions  by  AFS  per  year 
5.0  Reconsider  system  specification. 

5.1  Update  operation  parameters. 

INPUTS:  None 

OUTPUTS:  Number  of  PAA 
Sortie  Type 
Sortie  Rate  by  Type 
Sortie  Duration  by  Type 
AFS/Subsystem  Assignment 
Reliability  by  Subsystem  (Measured  Reliability) 
Maintenance  Tasks  by  Subsystem 
Maintenance  Task  Times 
Maintenance  Crew  Size  by  Task 

5 . 3  Propose  and  evaluate  revised  system  support  concepts. 

INPUTS:  Number  of  PAA 

Sortie  Type 
Sorrie  Rate  by  Type 
Sortie  Duration  by  Type 
AFS/Subsystem  Assignment 
Reliability  by  Subsystem  (Measured  Reliability) 
Support  Equipment 
Maintenance  Tasks  by  Subsystem 
Maintenance  Task  Times 
Maintenance  Crew  Size  by  Task 
OUTPUTS:  Predicted  Required  Manpower  by  AFS 
Predicted  System  Training  Requirements 
Predicted  Required  Accessions  by  AFS  per  year 

5 .4  Evaluate  candidate  system  upgrades. 

INPUTS:  Number  of  PAA 

Sortie  Type 
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Sortie  Rate  by  Type 
Sortie  Duration  by  Type 

OUTPUTS:  Predicted  Required  Manpower  by  AFS 
Predicted  System  Training  Requirements 
Predicted  Required  Accessions  by  AFS  per  year 

DataHigmsms 


AFS/Subsystem  Assignment 

Allocated  Required  Accessions  by  AFS  per  year 

Allocated  Required  Manpower  by  AFS 

Allocated  System  Maintainability 

Allocated  System  Reliability 

Allocated  System  Training  Requirements 

Comparability  Required  Accessions  by  AFS  per  year 

Comparability  Required  Manpower  by  AFS 

Comparability  System  Training  Requirements 

Historic  Personnel  Turnover  Rate  by  AFS 

Maintenance  Crew  Size,  by  Task 

Maintenance  Task  Times 

Maintenance  Tasks  by  Subsystem 

Number  ofPAA 

Predicted  Required  Accessions  by  AFS  per  year 
Predicted  Required  Manpower  by  AFS 
Predicted  System  Training  Requirements 
Predicted  Required  Manpower  by  AFS 
Reliability  by  Subsystem  (Allocated  Reliability) 
Reliability  by  Subsystem  (Comparable  Reliability) 
Reliability  by  Subsystem  (Measured  Reliability) 
Reliability  by  Subsystem  (Predicted  Reliability) 
Sortie  Duration  by  Type 
Sortie  Rate  by  Type 
Sortie  Type 
Support  Equipment 
Technology  Type  by  Subsystem 
Training  Requirements  by  AFS 
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APPENDIX  C:  LSAR  MPT  DATA  ELEMENTS  WITH  MPT/SE  DATA  ELEMENTS 

CROSS-REFERENCED 
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LSAR  MPT  DATA  ELEMENTS  WITH  MPT/SE  DATA  ELEMENTS  CROSS-REFERENCED 


Note:  The  distinction  among  comparable,  allocated,  predicted,  and  measured  parameters  is  not 
included  in  the  cross-reference  information.  The  only  possible  confusion  from  this  is  the 
distinction  between  system  maintainability  and  individual  task  time  blurs  where  level  of  analysis  is 
not  specified;  both  are  listed  where  applicable. 

Data  Record  A  (Operations  and  Maintenance  Requirements! 


Card  A06 

Annual  Operating  Requirements  (APR'):  Sortie  Rate  by  Type,  Sortie  Type 

Annual  Number  of  Missions:  Sortie  Rate  by  Type 

Annual  Operating  Davs:  Sortie  Rate  by  Type 

Mean  Mission  Duration:  Sortie  Duration  by  Type 

Total  Systems  Supported:  Number  of  PAA 

Number  of  Operating  Locations:  Number  of  PAA 

■CardLAQZ 

Minimum  Acceptable  Mean.Time  Between  Failures  (MTBF):  System  Reliability 
Minimum  Acceptable  Mean  Time  Between  Maintenance  Actions  (MTBMA):  System  Reliability 
Minimum  Acceptable  Mean  Time  to  Repair  (M'lTRI:  System  Maintainability 
Minimum  Acceptable  Mean  Active  Maintenance  Downtime  (MAMDT):  System  Maintainability, 
System  Reliability 

Best  Operational  Capability  ('BOO  Mean  Time  Between  Failures  (MTBF1:  System  Reliability 
BOC  Mean  Active  Between  Maintenance  Actions  fMTBMA’):  System  Reliability 
BOC  Mean  Time  to  Repair  CM  lTKI:  System  Maintainability 

BOC  Mean  Active  Maintenance  Downtime  CMAMDT):  System  Maintainability,  System 
Reliability 

CrnlA-M 

Maximum  Time  to  Repair  (MAX  lTRI:  System  Maintainability 

Precentile  (of  maintenance  actions  not  to  exceed  MAX  TTR):  System  Maintainability 

Inherent  Availability  CAi):  System  Reliability  System  Maintainability 

Achieved  Availability  (Aa):  System  Reliability,  System  Maintainability 

Operational  Availability  (Ao):  System  Reliability,  System  Maintainability 

Administrative  and  Logistic  Delay  Time  CALDT):  System  Maintainability 
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CacdAQa 

Operations/Maintenance  Level  (O/M  LVU:  AFS/Subsystem  Assignment 

Number  of  Systems  Supported:  Number  of  PAA 

Unscheduled  Maintenance  Mean  Elapsed  Time:  System  Maintainability 

Unscheduled  Maintenance  Mean  Man-Hours:  System  Maintainability 

Unscheduled  Maintenance  Maximum  Time  to  Repair  System  Maintainability 

Unscheduled  Maintenance  Percentile  (of  maintenance  actions  not  to  exceed  MAX  TTRk  System 

Maintainability 

Scheduled  Maintenance  Man-Hour  per  Operating  Hour:  System  Maintainability 
Unscheduled  Maintenance  Man-Hour  per  Operating  Hour:  System  Maintainability 
Scheduled  Maintenance  Annual  Man-Hours:  System  Maintainability 
Unscheduled  Maintenance  Annual  Man-Hours:  System  Maintainability 
Turnaround  Mean  F-lapsed  Time:  System  Maintainability,  Maintenance  Task  Times 
Turnaround  Mean  Man-Hours:  System  Maintainability,  Maintenance  Task  Times 

Card  A10 

Daily  Inspection  Mean  Elapsed  Time:  System  Maintainability,  Maintenance  Task  Times 
Daily  Inspection  Mean  Man-Hours:  System  Maintainability,  Maintenance  Task  Times 
Preoperative  Inspection  Mean  Elapsed  Time:  System  Maintainability,  Maintenance  Task  Times 
Preoperative  Inspection  Mean  Man-Hours:  System  Maintainability,  Maintenance  Task  Times 
Postoperative  Inspection  Mean  Elapsed  Time:  System  Maintainability,  Maintenance  Task  Times 
Postoperative  Inspection  Mean  Man-Hours:  System  Maintainability,  Maintenance  Task  Times 
Periodic  Inspection  Mean  Elapsed  Time:  System  Maintainability,  Maintenance  Task  Times 
Periodic  Mission  Inspection  Mean  Man-Hours:  System  Maintainability,  Maintenance  Task  Times 
Mission  Profile  Change  Mean  Elapsed  Time:  System  Maintainability,  Maintenance  Task 
Times 

Mission  Profile  Change  Mean  Man-Hours:  System  Maintainability,  Maintenance  Task 
Times 

Card  A li, 

Operations/Maintenance  Level:  AFS/Subsystem  Assignment 
Skill  Specialty  Code  (SSC):  AFS/Subsystem  Assignment,  Required  Manpower  by  AFS 
Skill  Level  Code  (SLQ:  AFS  Subsystem  Assignment,  Required  Accessions  by  AFS  per  Year, 
Required  Manpower  by  AFS 

Quantity  Skill  Specialty  Code  Available  (OTY  SSC  AVAID:  Required  Accessions  by  AFS  per 
Year,  Required  Manpower  by  AFS 
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i:  Required  Accessions  by 


Skill  Specialty  Code  Available  Man-Hours  (AVAIL  MAN-HOURS) 

AFS  per  Year,  Required  Manpower  by  AFS 

Data  Record  B  (Item  Reliability  and  Maintainability  Characteristics) 


Card  BQ.fi 

Inherent  Availability  (AO:  System  Maintainability,  System  Reliability 
Achieved  Availability  CAa1):  System  Maintainability,  System  Reliability 
Operational  Availability  CAo):  System  Maintainability,  System  Reliability 

Card  B07 

Reliabilitv/Maintainabilitv  Indicator  Code  (Comparability.  Allocated.  Predicted,  Measured):  Mean 

Time  Between  Failures  (MTBF):  System  Reliability 

Mean  Time  Between  Maintenance  Actions  (MTBMA’1:  System  Reliability 

Mean  Time  Between  Maintenance  Inherent  (MTBM  INHERENT):  System  Reliability 

Reliability  Growth  Rate:  System  Reliability 

Mean  Time  Between  Maintenance  Induced  (MTBM  INDUCED):  System  Reliability 

Mean  Time  Between  Maintenance  No  Defect  (MTBM  NO  DEFECT):  System  Reliability 

Mean  Time  Between  Preventative  Maintenance  (MTBPM1:  System  Reliability 

Mean  Time  To  Repair  (M'lTR):  System  Maintainability 

Maximum  Time  To  Repair  (MAX  TTR):  System  Maintainability 

Percentile  (of  maintenance  actions  not  to  exceed  MAX  ZEE}:  System  Maintainability 

Card  ?J1 

Reliability  Centered  (Preventative)  Maintenance  Task  Code:  Maintenance  Tasks  by  Subsystem 
Reliability  Centered  (Preventative)  Maintenance  Task  Time:  System  Maintainability,  Maintenance 
Task  Times 


Data  Record  B1  (Failure  Modes  and  Effects  Analysis') 


No  Relevant  Entries, 


Data  Record  B2  (Criticality  and  Maintainability  Analysis) 


Card  .MS 

Failure  Rate  (Component!:  System  Reliability 
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GffiLMS 

Task  Time  ('■Component):  System  Maintainability,  Maintenance  Task  Times 


Ratii-Rccord  C  (Operation  and  Maintenance  Task  Summary) 

■Qurd.C.Q6 

Task  Code:  Maintenance  Tasks  by  Subsystem 
Task  Frequency:  System  Reliability 

Training  Equipment  Requirements  Code  (TRN  EOP):  System  Training  Requirements 
Too!/S import  Equipment  Requirements  Codes:  Support  Equipment 

Data  Record  D  (Operation  and  Maintenance  Task  Analysis') 

Task  Code:  Maintenance  Tasks  by  Subsystem 

Person  Identifier  (PERS  ID):  indirect  means  to  compute  crew  size:  AFS/Subsystem  Assignment, 
Required  Manpower  by  AFS 

Mean  Man-Minutes:  System  Maintainability,  Maintenance  Task  Times 
Mean  Minute  Elasped  Time:  System  Maintainability,  Maintenance  Task  Times 
Skill  Specialty  Code:  AFS/Subsystem  Assignment 

Mean  Man-Minutes  per  Skill  Specialty  Code:  System  Maintainability,  Maintenance  Crew, 
Maintenance  Task  Times  Size  by  Task 

Mean  Minute  Total  Elapsed  Time:  System  Maintainability,  Maintenance  Task  Times 
Data  Record  D1  (Personnel  and  Support  Requirements) 

Card  DQ6 

Task  Code:  AFS/Subsystem  Assignment,  Maintenance  Tasks  by  Subsystem 

Predicted  Mean  Elapsed  Time:  System  Maintainability,  Maintenance  Task  Times 

Measured  Mean  Elapsed  Time:  System  Maintainability,  Maintenance  Task  Times 

Skill  Level  Code  (SLC)  (Basic.  Intermediate,  or  Advanced!:  AFS/Subsystem  Assignment, 

Required  Accessions  by  AFS  per  Year 

Skill  Specialty  Code  (SSO:  AFS/Subsystem  Assignment 

Skill  Specialty  Evaluation  Code  (SSEVAU  (Adequate.  Modification,  Establish  new  SSQ: 
AFS/Subsystem  Assignment 
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;  Required  Manpower  by  AFS, 


Maintenance  Crew  Size  by  Task 

Predicted  Mean  Man-Hours  Per  Skill  Specialty  Code:  System  Maintainability,  Maintenance  Crew 
Size  by  Task,  Maintenance  Task  Times 

Measured  Mean  Man-Hours  Per  Skill  Specialty  Code:  System  Maintainability,  Maintenance  Crew 
Size  by  Task,  Maintenance  Task  Times 

Data  Record  E  (Support  Equipment  or  Training  Material  Description  and  Justification) 

SupporLEquiTmgai-Rgquirgd.(S.E.REQUIH,gP): 

Calibration  Required:  Maintenance  Tasks  by  Subsystem 

Calibration  Time:  System  Maintainability,  Maintenance  Task  Times 

Mean  Time  Between  Failures  (MTBFk  System  Reliability 

Mean  Time  Between  Maintenance  Actions  (MTB.MA):  System  Reliability 

Mean  Time  To  Repair  (M'lTR):  System  Maintainability,  Maintenance  Task  Times 

Quantity  Per  Activity:  Number  of  PAA 

Total  Quantity:  Number  of  PAA 

Skill  Specialty  Code  fSSQ:  AFS/Subsystem  Assignment 

Additional  Skills  and  Special  Training  Requirements:  System  Training  Requirements 

Bata  .Record. El  (Unit  Underlest  andAitOTatigJBnpgramfe)) 

No  Relevant  Entries. 


Data.Rgg.Qrd,.F(Facilily.Dgsgripti2D.^dJ,»5nrigatlQ.n) 

No  Relevant  Entries. 


Data  Record  0  (Skill  EvaUiation.and.  Justification) 

Skill  Specialty  Code.  Assigned  New  Duty  Position  (SSC  ASSIGNED  NEW  DUTY,  POSITION!: 
AFS/Subsystem  Assignment 

Skill  Specialty  Code  From  Which  Personnel  Can  Be  Obtained:  AFS/Subsystem  Assignment, 
Required  Accessions  by  AFS  per  Year 
Minimal  Task  Score  Acceptable: 

Military  Rank/Rate:  AFS/Subsystem  Assignment,  Required  Accessions  by  AFS  per  Year 
Civilian  Grade:  AFS/Subsystem  Assignment 
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Physical  and  Mental  Requirements:  Required  Accessions  by  AFS  per  Year 

Educational  Qualifications:  Required  Accessions  by  AFS  per  Year,  System  Training  Requirements 

Additional  Training  Requirements:  System  Training  Requirements 

Pitta  Rcwrd.H  (Support  Items  Identification) 


No  Relevant  Entries. 


Data  Record. HI  (Support  Itgms.Ideniificatioii) 


No  Relevant  Entries. 

Data  Record  J  (Transportability  Engineering  Characteristics) 
No  Relevant  Entries. 
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APPENDIX  D:  LCOM  MPT  DATA  ELEMENTS 


LCOM  MPT  DATA  ELEMENTS 


No  Relevant  Entries. 


Form  10  (Performance  Summary  Report! 


Form  1 1  H'ask  Network1) 

Task  ID:  The  Work  Unit  Code  (WUC)  of  the  activity. 

Selection  Parameter:  The  failure  distribution  underlying  the  task  demand  and  the  parameter  for  that 
distribution. 


Form  12  (Task  Definitions') 


Task  ID:  The  WUC  of  the  activity. 

Task  Type:  The  distinction  between  scheduled  versus  unscheduled  is  made. 

Task  Duration:  Self-explanatory. 

Associated  Resources,  Rcso-Uice  Requirements, .Task  Sgsgific..RgSQurcg..$.ubstiiiitk>n..(FQrin,  1 2.A): 
Support  equipment  or  spares. 


Form  13.(R<?sourcs  Definitions) 

Resource  Identification:  Resource  Name;  not  a  federal  stock  number  (FSN). 

Resource  Type:  Aircraft,  parts,  manpower,  or  Aerospace  Ground  Equipment  (AGE). 
Authorized  Quantity:  Self-explanatory. 

Quantity  Per  Aircraft  (OPAk  Number  of  a  single  part  installed  on  the  aircraft.  Used  to  calculate 
cannibalization  effects  within  the  model. 

Form-14.  (Failure  .Clock  Decrements) 

Parameters  used  in  failure  rates  and  distribution  calculations. 

Form  .15  (Distributions) 

Parameters  used  in  failure  rates  and  distribution  calculations. 
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Parameters  used  to  develop  shift  policy  statistics  for  manpower  calculation. 

Fonn  17  (Mission/Activitv  Entry  Points') 


Mission  IP:  Sortie  Type 

Presonie  External  Configurations:  Determines  preflight  work  demand;  heterogeneous  sortie 
profiles  will  have  more  task  demand  than  will  homogeneous  task  profiles. 

Fonn  18  (Priority  Specifications! 

Parameters  used  to  model  task  demand  and  service  discipline. 

Form  2Q.  (Sortie  Generator) 

Number  of  Missions  or  Activities:  Sortie  Rate. 

Take-off  or  Activity  Time:  Determines  sortie  demand  distribution. 

Mission  Size:  Number  of  aircraft  required  for  each  mission. 

Mission  Length:  Self-expi  anatory. 

Form  21  (Aircraft  Assignment  Search  Pattern') 

Parameters  required  to  determine  pre-sortie  task  requirements. 

Form  22  (Internal  Equipment  Authorization/Changes') 

Parameters  required  to  determine  pre-sortie  task  requirements. 

Fonn  23  CIntemal  Equipment  Group  Definitions') 

Parameters  required  to  determine  pre-sortie  task  requirements. 
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APPENDIX  E:  DRAFT  MPT  DATA  MODEL 
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DRAFT  MPT  DATA  MODEL 


1.0  Develop  functional  description 

1 . 1  Identify  operational.'requirements 
Sortie  rates 

Sortie  duration 
Sortie  type 

Number,  of  assignediaircraft 

Base  layout'Itransportation, times  between- work. sites) 

1.2  Propose/develop  comparable-system 
Technology  type 

Sortie  type 

Support*  equipment  type 
AFS- responsibilities 
Reliability 

Maintenance  requirements 
Task  times 

1 .3  Perform  comparability,-  analysis 
AFS  responsibilities 

Shift  policy 
Reliability 

Maintenance  requirements 
Task  times 
Sortie  rates 
Sortie  duration 
Sortie  type 

Support  equipment  type 
Support  equipment  amount 
Spares  level 

Number  of  assigned  aircraft 

Base  layout  (transportation  times  between  work  sites) 

Required  manpower  by  AFS 

1 .4  Identify  predecessor  system 
Predecessor  AFS  structure 
Available  manpower  by  AFS 
Training  requirement  by  AFS 
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1 .5  Develop  preliminary  MPT  profile 
Predecessor  AFS  structure 
Available  manpower  by  AFS 
Training  requirement  by  AFS 
Required  manpower  by  AFS 
Required  accessions 
Required  training 

1.6  Propose  MPT  MOMs 
Support  equipment  type 
AFS  responsibilities 
Reliability 

Maintenance  requirements 
Task  times 
Shift  policy 

Support  equipment  amount 
Spares  level 

Number  of  assigned  aircraft 

Base  layout  (transportation  times  between  work  sites) 

Required  manpower  by  AFS 

Predecessor  AFS  structure 

Available  manpower  by  AFS 

Training  requirement  by  AFS 

Required  accensions 

MPT  MOMs 

2.0  Assign  functional  allocation 

2. 1  Update  operational  requirements* 

2.2  Allocate  MPT  MOMs  to  subsystems 
AFS  responsibilities 

Reliability 

Maintenance  requirements 
Task  times 
Support  equipment 
Spares  level 
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2.3  Estimate  MPT  MOMs  from  functionally  partitioned  system** 
AFS  responsibilities 
Reliability 

Maintenance  requirements 

Task  times 

Shift  policy 

Sortie  rates 

Sortie  duration 

Sortie  type 

Si”-  v>rt  equipment  type 
Support  equipment  amount 
Spares  level 

Number  of  assigned  aircraft 
Base  layout  (transportation  times  between  work  sites) 
Required  manpower  by  AFS 
3.0  Design  Subsystems 

3.1  Update  operational  requirements* 

3.2  Estimate  MPT  MOMs  from  subsystem  design** 

AFS  responsibilities 

Reliability 

Maintenance  requirements 
Task  times 
Shift  policy 
Sortie  rates 
Sortie  duration 
Sortie  type 

Support  equipment  type 
Support  equipment  amount 
Spares  level 

Number  of  assigned  aircraft 

Base  layout  (transportation  times  between  work  sites) 

Required  manpower  by  AFS 

3.3  Interact  with  design  activity 
4.0  Integrate  subsystems 

4. 3  Update  operational  requirements* 
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4.2  Estimate  MPT  MOMs  from  system  design** 

AFS  responsibilities 
Reliability 

Maintenance  requirements 

Task  times 

Shift  policy 

Sortie  rates 

Sortie  duration 

Sortie  type 

Support  equipment  type 
Support  equipment  amount 
Spares  level 

Number  of  assigned  aircraft 
Base  layout  (transportation  times  between  work  sites) 
Required  manpower  by  AFS 
5.0  Test  and  evaluation 

5. 1  Update  operational  requirements* 

5.2  Estimate  MPT  MOMs  from  test  results** 

AFS  responsibilities 

Reliability 

Maintenance  requirements 
Task  times 
Shift  policy 
Sortie  rates 
Sortie  duration 
Sortie  type 

Support  equipment  type 
Support  equipment  amount 
Spares  level 

Number  of  assigned  aircraft 
Base  Layout  (transportation  times  between  work  sites) 
Required  manpower  by  AFS 
6.0  Reconsider  system  specification 
6.1  Update  operation  parameters* 
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6.2  Compute  MPT  MOMs  from  field  experience** 

AFS  responsibilities 

Reliability 

Maintenance  requirements 
Task  times 
Shift  policy 
Sortie  rates 
Sortie  duration 
Sortie  type 

Support  equipment  type 
Support  equipment  amount 
Spares  level 

Number  of  assigned  aircraft 

Base  Layout  (transportation  times  between  work  sites) 

Required  manpower  by  AFS 

6.3  Propose  and  evaluate  system  support  concepts 
AFS  responsibilities 

Reliability 

Maintenance  requirements 
Task  times 
Shift  policy 
Sortie  rates 
Sortie  duration 
Sortie  type 

Support  equipment  type 
Support  equipment  amount 
Spares  level 

Required  manpower  by  AFS 

6.4  Propose  and  evaluate  system  upgrades 
AFS  responsibilities 

Reliability 

Maintenance  requirements 
Task  times 
Shift  policy 
Sortie  rates 
Sortie  duration 


E-6 


Sortie  type 

Support  equipment  type 
Support  equipment  amount 
Spares  level 

Required  manpower  by  AFS 

♦These  activities  loop  back  to  some  previous  point  in  the  SE  process, 
♦♦depending  upon  MOMs  selected 


